web-dev-qa-db-fra.com

type de données mysql pour stocker le mois et l'année uniquement

J'écris une application php qui stockera les données des étudiants dans une base de données relationnelle MySQL. J'essaie de trouver le meilleur moyen/type de données pour stocker un mois et une année ensemble sans le jour. Je ne sais pas si je devrais simplement le stocker en tant que DATE et utiliser php d'une manière ou d'une autre pour simplement stocker le jour en tant que 1er ou utiliser un type de données différent que je ne connais pas actuellement. Idéalement, je ne veux pas stocker un jour, car le jour ne sera pas toujours le même et nécessiterait de changer le code source php si le jour changeait à l'avenir.

Juste pour plus d'informations de fond, je stocke INTENT_TO_GRAD d'un ÉTUDIANT. Le client semble vouloir uniquement ces informations comme référence ou visuel pour un rapport plutôt que de les utiliser pour la manipulation de données. En d'autres termes, la seule exigence fonctionnelle de ces données doit être affichée dans un rapport.

mysqlsqldatabase-design
38
Daniel Wilhoit

Pourquoi s'embêter? Il suffit de le stocker comme une date complète (peut-être toujours en utilisant le premier comme jour) et d'utiliser les fonctions de base de données MONTH() et YEAR() = si vous n'en avez besoin que d'une partie. Cela rend l'utilisation de ce champ beaucoup plus facile car vous pouvez toujours effectuer des requêtes de plage, etc.

50
Brian Roach

Il est dit dans le manuel MySQL que vous pouvez stocker des dates partielles

http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_date-format

Les plages pour les spécificateurs de mois et de jour commencent par zéro en raison du fait que MySQL permet le stockage de dates incomplètes telles que '2014-00-00'.

Cela signifie que pour stocker l'année et le mois uniquement, vous pouvez utiliser une colonne DATE et mettre 00 au lieu du jour. par exemple 2013-12-00.

Connexes: Stocker la date incomplète dans le champ de date MySQL

56
Timo Huovinen

Considérez comment vous allez utiliser les données. S'il y a des rapports que vous devez créer, de quelle manière vous permettrait de récupérer et de travailler plus facilement avec les données?

Et vous n'avez pas besoin d'utiliser un champ de type date. Vous pouvez simplement avoir un champ Year et un champ Month qui sont tous deux des entiers. Ensuite, lorsque vous avez réellement besoin de faire n'importe quel type d'expression nécessitant une date, il est assez facile de les assembler et de les diffuser à une date.

Et stocker comme une date avec le numéro du jour comme 1 et simplement l'ignorer est parfaitement correct et assez normal aussi. En fin de compte, ce n'est pas une décision qui importera beaucoup (relativement parlant), donc je choisirais simplement celle que vous préférez et je la ferai.

5
Brandon Moore

Je stockerais les deux comme deux colonnes distinctes sous forme d'entiers. Cela ferait un gâteau de validation et permettrait des possibilités de tri et de regroupement rapides et faciles.

3
Kyle Macey
SELECT * FROM Users
WHERE 
    MONTH(DateTime) = '07'
AND 
    YEAR(DateTime) = '2015'
AND 
    DAY(DateTime) = '26'

vous pouvez filtrer comme ci-dessus, mais toujours si vous souhaitez stocker l'année/le mois et le jour séparément, c'est inutile jusqu'à ce que vous appliquiez l'indexation et ses très grandes données.

2
Furqan Freed

Une autre solution consiste à créer des colonnes générées à partir de votre source DATETIME/DATE.

ALTER TABLE stats 
ADD COLUMN year SMALLINT GENERATED ALWAYS AS (YEAR(stat_date)) NOT NULL,
ADD COLUMN month smallint GENERATED ALWAYS AS (MONTH(stat_date)) NOT NULL;

Contexte

J'avais un problème similaire. Après avoir lu ce fil, j'ai décidé de stocker des dates incomplètes (avec des zéros). Il fonctionnait sur les anciennes versions de MySQL, mais les versions plus récentes produisaient une erreur "date incorrecte". Comme mentionné précédemment, vous pouvez transformer l'erreur en avertissement en utilisant le paramètre NO_ZERO_IN_DATE. Mais le cadre lui-même est obsolète. Par conséquent, à l'avenir, il ne serait possible de prendre en charge les zéros dans les dates qu'en désactivant le mode strict, donc, en faisant taire d'autres types d'erreurs.

Parce que NO_ZERO_IN_DATE est obsolète, il sera supprimé dans une future version de MySQL en tant que nom de mode séparé et son effet inclus dans les effets du mode SQL strict.

Mon exigence était de construire une vue mensuelle d'une table. J'ai dû ajouter un index sur le mois. Donc, calculer le papillon à la volée avec YEAR() et MONTH() n'était pas une option.

Les colonnes générées ont rempli leur fonction. Les colonnes year et month ne faisaient pas partie de l'index principal, et je pouvais même économiser de l'espace grâce aux colonnes générées VIRTUAL (pas STORED) .

Liens

0
shapiy