Date-heure est une valeur
Les valeurs date-heure sont presque toujours suivies dans le logiciel en tant que valeurs uniques. Techniquement, ils sont représentés en interne en nombre de secondes/millisecondes/microsecondes/nanosecondes depuis une époque .
Vous voudrez peut-être présenter une date et une heure séparément dans l'interface utilisateur, mais pas en interne.
En outre, vous devriez presque certainement penser aux fuseaux horaires. Les programmeurs naïfs pensent souvent qu'ils peuvent ignorer les fuseaux horaires, mais il est presque certain que cela causera de l'angoisse plus tard.
Comprendre la gestion de la date et de l'heure par votre base de données
Différentes bases de données gèrent la date et l'heure différemment. Il est absolument crucial que vous lisiez la documentation, que vous jouiez, que vous expérimentiez et que vous appreniez exactement comment fonctionne votre base de données.
Postgres a une gestion excellente et sensible de la date et de l'heure. Même si vous utilisez une autre base de données, consultez l'excellente documentation de Postgres sur date- types de données de temps et fonctions date-heure (commandes) pour en savoir plus sur les différents problèmes et sur ce qui est défini par la norme SQL par rapport à ce qui est propre à votre base de données.
Stockez globalement, présentez localement
La date-heure est un problème étonnamment glissant et compliqué. Une clé pour maîtriser le problème est de travailler en UTC . Stockez vos valeurs date-heure dans la base de données (ou dans des fichiers sérialisés, ou des communications XML/JSON) en UTC. Écrivez la majeure partie de votre logique métier en UTC, sauf lorsque le fuseau horaire local est important, comme définir "le début d'un nouveau jour".
Lorsque vous présentez à l'utilisateur, utilisez le format ISO 8601 ou localisez-le dans son propre fuseau horaire (ou dans le fuseau horaire qu'il attend). Cela suit l'idée de base de l'internationalisation/localisation. Pour les valeurs de texte, vous utilisez certaines chaînes de clés dans votre code. Lors de la présentation dans l'interface utilisateur, vous mappez ces chaînes internes à des valeurs de texte localisées (traduites) pour l'interface utilisateur. Certains avec date-heure :UTC en interne, fuseau horaire local dans l'interface utilisateur.
Une mise en garde :vous voudrez peut-être également stocker une date-heure locale pour des raisons d'histoire. Les règles de fuseau horaire changent fréquemment et capricieusement à cause des politiciens et des bureaucrates. La base de données des fuseaux horaires de votre logiciel est peut-être obsolète. Ainsi, vous souhaiterez peut-être stocker ce que vous ou l'utilisateur pensez être une certaine date et heure alors . Mais ne vous y fiez pas; déterminer et stocker la valeur UTC.
Conseil :Apprenez à penser et à lire en 24 heures. Votre vie en tant que programmeur/débogueur/administrateur système deviendra beaucoup plus facile et moins sujette aux erreurs.
Joda-Time ou java.time
Les classes java.util.Date et .Calendar fournies avec Java sont notoirement gênantes. Évite-les.
Utilisez plutôt Joda-Time ou le nouveau package java.time intégré à Java 8 (inspiré de Joda-Time, défini par JSR 310).
Les deux bibliothèques utilisent les formats ISO 8601 par défaut, à la fois pour l'analyse et la génération de chaînes.
ISO 8601
ISO 8601 est une norme sensée définissant comment présenter les valeurs date-heure, les fuseaux horaires et les décalages, les durées et les périodes dans des formats textuels spécifiques et non ambigus. Étudiez cette page Wikipédia bien écrite.
Notez en particulier ce que la norme appelle Durées
. Un intervalle de temps est défini dans ce format :PnYnMnDTnHnMnS où P signifie "Période", le T sépare la partie date de la partie heure, et les autres parties facultatives sont des chiffres + une lettre. Un rendez-vous d'une demi-heure serait PT30M . Cela peut être pratique pour vous, comme pour le champ "period_" vu dans mon DRE
dessous. Dans Joda-Time, la classe Period représente une période de temps en suivant ses mois, jours, heures, etc., et sait comment analyser et générer des chaînes dans ce format.
Semi-ouvert
Vous pouvez choisir de stocker les rendez-vous de deux manières. Une façon est une date-heure de début et une durée (90 minutes, 20 minutes, etc.). Une autre méthode consiste à enregistrer à la fois une date et une heure de début et de fin. Dans ce cas, l'approche habituelle et généralement la meilleure est appelée "Semi-ouverte". Cela signifie que le début est inclusif tandis que la fin est exclusive .
Par exemple, un rendez-vous d'une heure sur l'heure se déroulerait de 11h00 à 12h00, ce qui signifie "commençant à 11h00 et se poursuivant jusqu'au premier instant de l'heure suivante (midi) non compris". Le prochain rendez-vous aura lieu de 12h00 à 13h00.
Recherchez "Semi-ouvert" dans StackOverflow pour trouver plus de discussions, des exemples et des diagrammes.
Plusieurs à plusieurs
La relation entre Patient et Docteur est ce que nous appelons Many-To-Many . Un médecin voit de nombreux patients et un patient peut voir plus d'un médecin. Assurez-vous de connaître les tables Many-To-Many dans la conception de bases de données relationnelles. La solution consiste toujours à ajouter une troisième table, parfois appelée table "pont", qui sert de table enfant aux deux autres tables parentes. Dans votre cas, le Rendez-vous table est la table de pont.
Vous devrez savoir comment effectuer des jointures dans une relation plusieurs-à-plusieurs.
SQL direct
Si vous débutez en programmation ou en base de données relationnelle, je vous suggère d'éviter Hibernate. Vous devriez vraiment comprendre ce qui se passe. Hibernate a des utilisations appropriées. Mais si vous pensez qu'Hibernate va faire disparaître comme par magie les problèmes de base de données, vous serez déçu.
Attributs
Les attributs dépendent de vous. Ils dépendent du problème d'entreprise (ou des devoirs ?) que vous essayez de résoudre. Vous avez les bases.
La prise de rendez-vous est un problème commercial très difficile pour lequel écrire un logiciel. Par exemple, enregistrez-vous simplement les rendez-vous pris ? Ou suivez-vous la disponibilité des médecins, en créant des créneaux horaires prédéfinis, et si oui, comment gérez-vous les exceptions et les modifications apportées au calendrier de chaque médecin ? Vous devez rédiger des exigences et des cas d'utilisation très spécifiques. Il est très facile pour les utilisateurs de dépasser vos attentes supposées.
Voici une vue simpliste.
