Datum-tid är ett värde
Datum-tid-värden spåras nästan alltid i programvaran som enskilda värden. Tekniskt sett representeras de internt som ett antal sekunder/millisekunder/mikrosekunder/nanosekunder sedan en epok .
Du kanske vill presentera ett datum och en tid separat i användargränssnittet, men inte internt.
Dessutom bör du nästan säkert tänka på tidszoner. Naiva programmerare tror ofta att de kan ignorera tidszoner, men det kommer nästan säkert att orsaka ångest senare.
Förstå din databas hantering av datum-tid
Olika databaser hanterar datum-tid olika. Helt avgörande att du läser dokumenten, leker, experimenterar och lär dig exakt hur din databas fungerar.
Postgres har utmärkt och vettig hantering av datum-tid. Även om du använder en annan databas, se den utmärkta Postgres-dokumentationen på date- tidsdatatyper och datum-tid-funktioner (kommandon) för att lära dig om de olika frågorna och om vad som definieras av SQL-standarden jämfört med din databas.
Lagra globalt, presentera lokalt
Date-Time är ett förvånansvärt halt och komplicerat problem. En nyckel för att hålla kvar problemet är att fungera i UTC . Lagra dina datum-tid-värden i databasen (eller i serialiserade filer eller XML/JSON-kommunikation) i UTC. Skriv det mesta av din affärslogik i UTC, förutom där den lokala tidszonen är viktig, som att definiera "början på en ny dag".
När du presenterar för användaren, använd antingen ISO 8601-format eller lokalisera till sin egen tidszon (eller den tidszon de förväntar sig). Detta följer grundtanken om internationalisering/lokalisering. För textvärden använder du vissa nyckelsträngar i din kod. Vid presentation i användargränssnittet mappar du de interna strängarna till lokaliserade (översatta) textvärden för användargränssnittet. Vissa med datum-tid:UTC internt, lokal tidszon i användargränssnittet.
En varning:Du kanske vill också lagra en lokal datum-tid för historiens skull. Tidszonsreglerna ändras ofta och nyckfullt på grund av politiker och byråkrater. Din programvaras tidszondatabas kan vara inaktuell. Så du kanske vill lagra vad du eller användaren trodde var ett visst datum och tid då . Men lita inte på det; bestämma och lagra UTC-värdet.
Tips:Lär dig tänka och läsa på 24 timmar. Ditt liv som programmerare/debugger/sysadmin kommer att bli mycket enklare och mindre felbenäget.
Joda-Time eller java.time
Klasserna java.util.Date och .Calendar med Java är notoriskt besvärliga. Undvik dem.
Använd istället antingen Joda-Time eller det nya java.time-paketet inbyggd i Java 8 (inspirerad av Joda-Time, definierad av JSR 310).
Båda biblioteken använder ISO 8601-format som standard, både för att analysera och generera strängar.
ISO 8601
ISO 8601 är en förnuftig standard som definierar hur man presenterar datum-tid-värden, tidszoner och förskjutningar, varaktigheter och perioder i specifika och icke-tvetydiga textformat. Studera den välskrivna Wikipedia-sidan.
Notera särskilt vad standarden kallar Längder
. Ett tidsintervall definieras i detta format:PnYnMnDTnHnMnS där P betyder "Period", T separerar datumdelen från tidsdelen, och de andra valfria delarna är siffror + bokstav. En halvtimmes tid skulle vara PT30M . Detta kan vara praktiskt för dig, till exempel för fältet "period_" som visas i min ERD
Nedan. I Joda-Time representerar klassen Period ett tidsintervall genom att spåra dess månader, dagar, timmar, etc., och vet hur man både analyserar och genererar strängar i detta format.
Halvöppen
Du kan välja att lagra möten på något av två sätt. Ett sätt är ett startdatum-tid och en varaktighet (90 minuter, 20 minuter, etc.). Ett annat sätt är att spela in både start- och stoppdatum-tid. I det här fallet kallas det vanliga och generellt bästa tillvägagångssättet "Halvöppet". Det betyder att början är inkluderande medan slutet är exklusivt .
Till exempel skulle ett möte på en timme löpa från 11:00 till 12:00, vilket betyder "börjar kl 11 och löper fram till, men inte inklusive, den första stunden av nästa timme (middag)". Nästa möte kommer att pågå från 12:00 till 13:00.
Sök i StackOverflow efter "Halvöppet" för att hitta fler diskussioner och exempel och diagram.
Många-till-många
Relationen mellan patient och läkare är vad vi kallar Many-To-Many . En läkare träffar många patienter, och en patient kan träffa mer än en av läkarna. Se till att du känner till många-till-många-tabeller i relationsdatabasdesign. Lösningen är alltid att lägga till en tredje tabell, ibland kallad en "bro"-tabell som fungerar som en underordnad tabell till båda de andra överordnade tabellerna. I ditt fall, Avbokning bord är bryggbordet.
Du kommer att behöva veta hur du gör kopplingar i en många-till-många-relation.
Direkt SQL
Om du är ny på programmering eller ny på relationsdatabas, föreslår jag att du undviker Hibernate. Du borde verkligen få ett grepp om vad som pågår. Hibernate har några lämpliga användningsområden. Men om du tror att Hibernate magiskt kommer att få databasproblem att försvinna, kommer du att bli besviken.
Attribut
Attribut är upp till dig. De beror på affärs- (eller läxor?) problem du försöker lösa. Du har grunderna rätt.
Bokning av möten är ett mycket svårt affärsproblem att skriva programvara för. Till exempel, registrerar du helt enkelt möten som görs? Eller spårar du tillgängligheten för läkarna genom att skapa fördefinierade tidsluckor, och i så fall hur hanterar du undantag och ändringar i varje läkares kalender? Du måste skriva mycket specifika krav och användningsfall. Mycket lätt för användarnas förväntningar att överträffa dina förmodade krav.
Här är en förenklad bild.
