Dato-tid er én værdi
Dato-tidsværdier spores næsten altid i software som enkelte værdier. Teknisk set er de repræsenteret internt som et antal sekunder/millisekunder/mikroseconds/nanoseconds siden en epoke .
Du ønsker måske at præsentere en dato og et klokkeslæt separat i brugergrænsefladen, men ikke internt.
Desuden bør du næsten helt sikkert tænke på tidszoner. Naive programmører tror ofte, at de kan ignorere tidszoner, men det er næsten sikkert, at det forårsager angst senere.
Forstå din databases håndtering af dato-klokkeslæt
Forskellige databaser håndterer dato-tid forskelligt. Det er helt afgørende, at du læser dokumenterne, leger, eksperimenterer og lærer præcis, hvordan din database fungerer.
Postgres har fremragende og fornuftig håndtering af dato-tid. Selv hvis du bruger en anden database, kan du se den fremragende Postgres-dokumentation på date- tidsdatatyper og dato-tidsfunktioner (kommandoer) for at lære om de forskellige problemer og om, hvad der er defineret af SQL-standarden i forhold til din database.
Gem globalt, præsenter lokalt
Date-Time er et overraskende glat og kompliceret problem. En nøgle til at holde på problemet er at arbejde i UTC . Gem dine dato-tidsværdier i databasen (eller i serialiserede filer eller XML/JSON-kommunikation) i UTC. Skriv det meste af din forretningslogik i UTC, undtagen hvor den lokale tidszone har betydning, såsom at definere "begyndelsen af en ny dag".
Når du præsenterer for brugeren, skal du enten bruge ISO 8601-format eller lokalisere til deres egen tidszone (eller den tidszone, de forventer). Dette følger grundtanken om internationalisering/lokalisering. Til tekstværdier bruger du visse nøglestrenge i din kode. Ved præsentation i brugergrænsefladen kortlægger du disse interne strenge til lokaliserede (oversatte) tekstværdier for brugergrænsefladen. Nogle med dato-tid:UTC internt, lokal tidszone i brugergrænsefladen.
En advarsel:Du vil måske også gem en lokal dato-tid for historiens skyld. Tidszonereglerne ændres hyppigt og lunefuldt på grund af politikere og bureaukrater. Din softwares tidszonedatabase kan være forældet. Så du vil måske gemme, hvad du eller brugeren troede var en bestemt dato og klokkeslæt da . Men stol ikke på det; bestemme og gem UTC-værdien.
Tip:Lær at tænke og læse på 24 timers tid. Dit liv som programmør/debugger/sysadmin bliver meget nemmere og mindre udsat for fejl.
Joda-Time eller java.time
Java.util.Date og .Calendar klasserne, der er bundtet med Java, er notorisk besværlige. Undgå dem.
Brug i stedet enten Joda-Time eller den nye java.time-pakke indbygget i Java 8 (inspireret af Joda-Time, defineret af JSR 310).
Begge biblioteker bruger ISO 8601-formater som standard til både parsing og generering af strenge.
ISO 8601
ISO 8601 er en fornuftig standard, der definerer, hvordan man præsenterer dato-tidsværdier, tidszoner og forskydninger, varigheder og perioder i specifikke og ikke-tvetydige tekstformater. Studer den velskrevne Wikipedia-side.
Bemærk især, hvad standarden kalder Varigheder
. Et tidsrum er defineret i dette format:PnYnMnDTnHnMnS hvor P betyder "Periode", T adskiller datodelen fra tidsdelen, og de andre valgfrie dele er cifre + bogstav. En halv times aftale ville være PT30M . Dette kan være praktisk for dig, f.eks. for feltet "periode_", der ses i min ERD
under. I Joda-Time repræsenterer klassen Periode et tidsrum ved at spore dets måneder, dage, timer osv. og ved, hvordan man både parser og genererer strenge i dette format.
Halvåbent
Du kan vælge at gemme aftaler på en af to måder. En måde er en startdato-tid og en varighed (90 minutter, 20 minutter osv.). En anden måde er at registrere både en start- og stopdato-tid. I dette tilfælde kaldes den sædvanlige og generelt bedste tilgang "Halv-Åben". Det betyder, at begyndelsen er inklusiv mens slutningen er eksklusiv .
For eksempel vil en en-times aftale på timen løbe fra kl. 11.00 til 12.00, hvilket betyder "startende kl. 11.00 og løber op til, men ikke inklusive, det første øjeblik i den næste time (middag)". Den næste aftale løber fra kl. 12.00 til 13.00.
Søg i StackOverflow efter "Halv-åben" for at finde flere diskussioner og eksempler og diagrammer.
Mange-til-mange
Forholdet mellem Patient og læge er det, vi kalder Many-To-Many . En læge ser mange patienter, og en patient kan se mere end én af lægerne. Vær sikker på, at du kender til Mange-til-mange-tabeller i relationelt databasedesign. Løsningen er altid at tilføje en tredje tabel, nogle gange kaldet en "bro"-tabel, der fungerer som en undertabel til begge de andre overordnede tabeller. I dit tilfælde er Aftalen bord er brobordet.
Du bliver nødt til at vide, hvordan du udfører joinforbindelser på tværs af et mange-til-mange-forhold.
Direkte SQL
Hvis du er ny til programmering eller ny til relationel database, foreslår jeg, at du undgår Hibernate. Du burde virkelig få fat i, hvad der foregår. Hibernate har nogle passende anvendelser. Men hvis du tror, at Hibernate på magisk vis vil få databaseproblemer til at forsvinde, vil du blive skuffet.
Attributter
Attributter er op til dig. De afhænger af det forretnings- (eller lektier?) problem, du forsøger at løse. Du har det grundlæggende i orden.
Aftaleplanlægning er et meget vanskeligt forretningsproblem at skrive software til. Registrerer du for eksempel blot, at aftaler bliver lavet? Eller sporer du lægernes tilgængelighed ved at oprette foruddefinerede tidsintervaller, og i så fald, hvordan håndterer du undtagelser og ændringer i hver læges kalender? Du skal skrive meget specifikke krav og use-cases. Meget let for brugernes forventninger at overstige dine formodede krav.
Her er et forenklet billede.
