Discussion :

[laurentSc]

Bonjour,

je conçois une table MySql dont une des colonnes doit contenir des dates au format MM-YY. Quel est le meilleur choix de type (DATE, DATETIME ou autre chose ?) ?

[escartefigue]

bonjour,

Expliquez le contexte fonctionnel : quel est le besoin ?
Mais a priori, créez une colonne de type date (avec l'année donc) et supprimez l'année au moment de la restitution.
Ainsi vous bénéficierez de tous les contrôles liés au type date (validité de la date) et de toutes les fonctions associées (ajout de jours, décalage, jour de la semaine correspondant...)

[soazig]

Bonjour,
Je suis d'accord avec Escartefigue sur le fait que nous avons besoin du contexte.
Et notamment est-ce que ce mois de l'année sera présent dans plusieurs tables ou pas.
Escartefigue, j'ai l'impression que tu as mal lu, laurent a besoin du mois et de l'année sur 2 caractères mais pas du jour.

Personnellement sans contexte, je partirai sur une table des mois
Clé entier ANNEE+MOIS sur 2 chiffre (201901, 201902,...2019-03)
Année entier
Mois entier
AnneeeMoisAffichee char(5) qui contiendrait 01-19, 02-19
optionnel un entier sequentiel qui donnerait le nombre de mois depuis un mois donné (ce qui permettrait d'ajouter facilement 3 mois sans se demander si on a changé d'année ou pas.

Et une foreign key sur cette table dans ta table finale
ce qui me semble certain est qu'il ne faut pas stocker le mois en char(5) sous la forme demandée 01-19, sinon pour les tri ce sera l'enfer.

Cordialement
Soazig

[al1_24]

Ou bien une colonne de type date où on ne placera que les premiers jours du mois.
Ce qui permet de profiter de toutes les fonctions de gestion de date...
Ensuite, pour le format, ce n'est qu'une question d'affichage.

[laurentSc]

Bonjour,

merci pour vos réponses que je ne vois que maintenant, ayant oublié de demander une notification...

Le contexte : tout ce que je peux dire, c'est que je vais récupérer des fichiers csv dont chaque ligne (17 colonnes) décrit une demande d'intervention, avec notamment le produit concerné, un horodatage, le status, le lieu, le nom de la personne qui l'a soumise, etc.
Je pense donc que la date ne sera que dans une seule table. (l'idée étant de stocker les informations puis de pouvoir les afficher)

S'il y a plusieurs tables, c'est uniquement pour optimiser la taille des tables. Par exemple, il y a une colonne Priority avec les valeurs low, medium ou high. Plutôt que stocker à chaque fois ces chaînes de caractères, je vois une table Priority (id, name) avec 3 enregistrements : (1, low) (2, medium) (3, high) où la clé primaire sera id et dans ma table principale une clé étrangère contenant une de ces 3 valeurs.

En résumé de vos réponses, la colonne sera de type DATE (YYYY-MM-DD) (ce qui donnera donc accès à toutes les fonctions de manipulation de date) et comme le jour n'a aucune importance, j'y mettrai 01. C'est OK ? (ne connaissant pas tous les types disponibles, j'hésitais pour choisir la formule la plus économe en taille mémoire).

[escartefigue]

Oui, une colonne date dont la partie joue est valorisée à "01" c'est parfait