Question similaire: Sélection des anniversaires Postgres
Nous concevons une nouvelle fonctionnalité: nous stockons les parties du mois et de la journée des anniversaires des gens, mais pas l'année. Donc, un utilisateur né à Noël aura l'anniversaire "12/25". La question est, comment pouvons-nous le mieux représenter cela chez Postgres?
DATE nécessite une année et rejette également les sauts de sauts en cas de non-billee. Nous pourrions stocker tous les anniversaires avec une année de bissure arbitraire, par ex. '1972-12-25' , mais ce serait un peu d'un kludge.
- Nous pourrions utiliser deux colonnes
int , un pour le mois et un pour l'année, mais nous perdions entièrement la date intégrée de PG, et vous pourriez stocker la date '02 -31 '.
- Nous pourrions utiliser une colonne de texte , mais interrogez-le contre cela ne serait pas joli.
Y a-t-il des options que nous manquons? Nous nous appuyons actuellement vers une paire de colonnes entier.
EDIT:
Pourquoi ne pas simplement stocker la date de naissance - qui doit être une date valide-, et
aller de là?
Confidentialité - Il s'agit d'une fonctionnalité facultative et nous ne voulons pas demander plus d'informations personnelles que nécessaire.
3 Réponses :
stocker simplement la date avec un ascigeur arbitraire et le formater comme besoin de sélectionner.
J'ai un certain nombre de cas où je fais exactement cela. C'est tellement plus facile que toutes les autres idées.
Si l'année de naissance est
Le stocker sous 2400 ou 1804 pourrait causer des problèmes si vous (accidentellement?) Convertissez-la en horodatage de style UNIX. 1972 n'a pas ce problème, mais il a l'inconvénient qu'il pourrait facilement être une date de naissance valide. 2036 évite les deux problèmes, mais seulement jusqu'à ce que vous commenciez à recevoir des personnes nées en 2036 dans votre base de données. Peut-être utiliser 1972 plus un drapeau vous indiquant si l'année est valide?
@Keiththompson ouais, bon point. Dépend vraiment de ce dont vous avez besoin. Pense avant d'agir.
Étant donné que les fonctions habituelles de la date des postgres ne vous aideront pas vraiment à vous aider, il semble préférable de stocker le mois et la journée en tant que colonnes entières. Vous ne serez pas en mesure de "valider" la date de vérifier que la journée ne dépasse pas le nombre maximum de jours au cours du mois donné (si l'utilisateur entre 29 février, vous ne pouvez pas vraiment discuter avec eux).
Si vous êtes préoccupé par la validité des données, vous pourriez avoir la paire de mois / jour d'être une clé étrangère dans une table qui stocke 366 lignes, une pour chaque paire de mois / jour valide.
Vous avez peut-être toujours besoin de gérer le 29 février spécialement si vous faites quelque chose comme envoyer des salutations d'anniversaire à un utilisateur.
Ceci est plus d'une validation côté client.
Nous avions l'habitude d'offrir aux utilisateurs une liste de mois et de jours.
Vérifiez-le avant la soumission de formulaire.
Stockez-le dans une table sous forme de colonne à chaîne unique, qui est indexée.
Chaque jour, un travail cron, analyse toutes les entrées valides relevant de la combinaison de jour / mois d'aujourd'hui et de messages d'accueil à leur boîte aux lettres conformément au type d'occasion comme (anniversaire ou datée de naissance), etc.
La validation du côté client n'est jamais une preuve de plein temps.
Pourquoi ne pas simplement stocker la date de naissance - qui doit être une date valide et aller de là?
@ K-Ballo: Peut-être que la situation ne permet pas de connaître l'année de la naissance d'un utilisateur.