Datum-tijd is één waarde
Datum-tijdwaarden worden in software bijna altijd als afzonderlijke waarden bijgehouden. Technisch gezien worden ze intern weergegeven als een telling van seconden/milliseconden/microseconden/nanoseconden sinds een tijdperk .
Misschien wilt u een datum en een tijd apart in de gebruikersinterface presenteren, maar niet intern.
Ook moet u vrijwel zeker aan tijdzones denken. Naïeve programmeurs denken vaak dat ze tijdzones kunnen negeren, maar dat zal later ongetwijfeld voor angst zorgen.
Begrijp hoe uw database met datum-tijd omgaat
Verschillende databases gaan anders om met datum-tijd. Absoluut cruciaal dat u de documenten leest, speelt, experimenteert en precies leert hoe uw database werkt.
Postgres heeft een uitstekende en verstandige omgang met datum-tijd. Zelfs als u een andere database gebruikt, raadpleegt u de uitstekende Postgres-documentatie op date- tijdgegevenstypen en datum-tijd-functies (commando's) om meer te weten te komen over de verschillende problemen en over wat wordt gedefinieerd door de SQL-standaard versus specifiek voor uw database.
Globaal opslaan, lokaal presenteren
Date-Time is een verrassend glibberig en gecompliceerd probleem. Een sleutel om het probleem onder controle te houden, is werken in UTC . Sla uw datum-tijd-waarden op in de database (of in geserialiseerde bestanden of XML/JSON-communicatie) in UTC. Schrijf de meeste van uw bedrijfslogica in UTC, behalve waar de lokale tijdzone van belang is, zoals het definiëren van "het begin van een nieuwe dag".
Wanneer u aan de gebruiker presenteert, gebruikt u de ISO 8601-indeling of lokaliseert u naar hun eigen tijdzone (of de tijdzone die ze verwachten). Dit volgt het basisidee van internationalisering/lokalisatie. Voor tekstwaarden gebruik je bepaalde sleutelreeksen in je code. Bij presentatie in de gebruikersinterface wijst u die interne strings toe aan gelokaliseerde (vertaalde) tekstwaarden voor de gebruikersinterface. Sommige met datum-tijd:UTC intern, lokale tijdzone in gebruikersinterface.
Een waarschuwing:misschien wilt u ook bewaar een lokale datum-tijd omwille van de geschiedenis. Tijdzoneregels veranderen vaak en grillig vanwege politici en bureaucraten. De tijdzonedatabase van uw software is mogelijk verouderd. Dus misschien wilt u opslaan wat u of de gebruiker veronderstelde een bepaalde datum-tijd te zijn dan . Maar vertrouw er niet op; bepaal en bewaar de UTC-waarde.
Tip:Leer denken en lezen in 24 uur tijd. Je leven als programmeur/debugger/sysadmin wordt een stuk eenvoudiger en minder foutgevoelig.
Joda-Time of java.time
De klassen java.util.Date en .Calendar die bij Java worden geleverd, zijn notoir lastig. Vermijd ze.
Gebruik in plaats daarvan ofwel Joda-Time of het nieuwe java.time-pakket ingebouwd in Java 8 (geïnspireerd door Joda-Time, gedefinieerd door JSR 310).
Beide bibliotheken gebruiken ISO 8601-formaten als standaard, voor zowel het ontleden als het genereren van strings.
ISO 8601
ISO 8601 is een verstandige standaard die definieert hoe datum-tijdwaarden, tijdzones en offsets, duur en perioden in specifieke en ondubbelzinnige tekstformaten moeten worden weergegeven. Bestudeer die goed geschreven Wikipedia-pagina.
Merk in het bijzonder op wat de standaard Duur
noemt . Een tijdspanne wordt gedefinieerd in dit formaat:PnYnMnDTnHnMnS waar P betekent "Periode", de T scheidt het datumgedeelte van het tijdgedeelte, en de andere optionele delen zijn cijfers + letter. Een afspraak van een half uur is PT30M . Dit kan handig voor je zijn, zoals voor het veld "period_" dat te zien is in mijn ERD
onderstaand. In Joda-Time vertegenwoordigt de klasse Period een tijdsspanne door de maanden, dagen, uren, enz. bij te houden, en weet hij zowel tekenreeksen in dit formaat te ontleden als te genereren.
Halfopen
U kunt ervoor kiezen om afspraken op twee manieren op te slaan. Een manier is een startdatum-tijd &een duur (90 minuten, 20 minuten, etc.). Een andere manier is om zowel een start- als een stopdatum-tijd vast te leggen. In dit geval wordt de gebruikelijke en over het algemeen beste benadering "Half-Open" genoemd. Dit betekent dat het begin inclusief is terwijl het einde exclusief is .
Een afspraak van één uur op het hele uur zou bijvoorbeeld lopen van 11:00 tot 12:00 uur, wat betekent "vanaf 11.00 uur en loopt tot, maar niet inclusief, het eerste moment van het volgende uur ('s middags)". De volgende afspraak loopt van 12.00 tot 13.00 uur.
Zoek in StackOverflow naar "Half-open" om meer discussie en voorbeelden en diagrammen te vinden.
Veel-op-veel
De relatie tussen Patiënt en Dokter is wat we Many-To-Many noemen . Een arts ziet veel patiënten en een patiënt kan meer dan één van de artsen zien. Zorg ervoor dat u op de hoogte bent van Many-To-Many-tabellen bij het ontwerpen van relationele databases. De oplossing is altijd om een derde tabel toe te voegen, ook wel een "brug"-tabel genoemd, die dient als een onderliggende tabel voor beide andere bovenliggende tabellen. In uw geval de Afspraak tafel is de brugtafel.
U moet weten hoe u joins kunt uitvoeren in een veel-op-veel-relatie.
Directe SQL
Als u nieuw bent in programmeren of nieuw bent in relationele databases, raad ik aan Hibernate te vermijden. Je moet echt begrijpen wat er aan de hand is. Hibernate heeft een aantal geschikte toepassingen. Maar als u denkt dat Hibernate op magische wijze databaseproblemen zal laten verdwijnen, zult u teleurgesteld zijn.
Kenmerken
Attributen zijn aan jou. Ze zijn afhankelijk van het zakelijke (of huiswerk?) probleem dat u probeert op te lossen. Je hebt de basis goed.
Afspraakplanning is een zeer moeilijk zakelijk probleem waarvoor software moet worden geschreven. Legt u bijvoorbeeld alleen gemaakte afspraken vast? Of houdt u de beschikbaarheid van de artsen bij door vooraf gedefinieerde tijdvakken te creëren, en zo ja, hoe gaat u om met uitzonderingen en wijzigingen in de agenda van elke arts? U moet zeer specifieke vereisten en use-cases schrijven. Het is heel gemakkelijk voor de verwachtingen van gebruikers om uw veronderstelde vereisten te overtreffen.
Hier is een simplistische weergave.
