Data-ora è un valore
I valori di data e ora vengono quasi sempre registrati nel software come valori singoli. Tecnicamente sono rappresentati internamente come un conteggio di secondi/millisecondi/microsecondi/nanosecondi da un epoca .
Potresti voler presentare una data e un'ora separatamente nell'interfaccia utente, ma non internamente.
Inoltre, quasi sicuramente dovresti pensare ai fusi orari. I programmatori ingenui spesso pensano di poter ignorare i fusi orari, ma è quasi certo che ciò causerà angoscia in seguito.
Comprendi la gestione della data-ora da parte del tuo database
Database diversi gestiscono la data e l'ora in modo diverso. Assolutamente fondamentale che tu legga i documenti, giochi, sperimenti e impari esattamente come funziona il tuo database.
Postgres ha un'eccellente e ragionevole gestione della data e dell'ora. Anche se utilizzi un altro database, consulta l'eccellente documentazione di Postgres su date- tipi di dati temporali e funzioni data-ora (comandi) per conoscere le varie problematiche e ciò che è definito dallo standard SQL rispetto a quello peculiare del tuo database.
Conserva a livello globale, presenta localmente
Date-Time è un problema sorprendentemente scivoloso e complicato. Una chiave per tenere sotto controllo il problema è lavorare in UTC . Archivia i valori di data e ora nel database (o in file serializzati o comunicazioni XML/JSON) in formato UTC. Scrivi la maggior parte della tua logica aziendale in UTC, tranne quando il fuso orario locale è importante, come definire "l'inizio di un nuovo giorno".
Quando ti presenti all'utente, utilizza il formato ISO 8601 o localizza il proprio fuso orario (o il fuso orario previsto). Ciò segue l'idea di base di internazionalizzazione/localizzazione. Per i valori di testo, utilizzi determinate stringhe di chiavi nel tuo codice. Al momento della presentazione nell'interfaccia utente, si associano quelle stringhe interne a valori di testo localizzati (tradotti) per l'interfaccia utente. Alcuni con data e ora:UTC internamente, fuso orario locale nell'interfaccia utente.
Un avvertimento:potresti voler anche memorizzare una data e ora locale per motivi di cronologia. Le regole del fuso orario cambiano frequentemente e in modo capriccioso a causa di politici e burocrati. Il database del fuso orario del software potrebbe non essere aggiornato. Quindi potresti voler memorizzare ciò che tu o l'utente riteneva fosse una certa data e ora allora . Ma non fare affidamento su di esso; determinare e memorizzare il valore UTC.
Suggerimento:impara a pensare e leggere in 24 ore. La tua vita da programmatore/debugger/amministratore di sistema diventerà molto più semplice e meno soggetta a errori.
Joda-Time o java.time
Le classi java.util.Date e .Calendar in bundle con Java sono notoriamente problematiche. Evitali.
Utilizzare invece Joda-Time o il nuovo pacchetto java.time integrato in Java 8 (ispirato a Joda-Time, definito da JSR 310).
Entrambe le librerie utilizzano i formati ISO 8601 come predefiniti, sia per l'analisi che per la generazione di stringhe.
ISO 8601
ISO 8601 è uno standard ragionevole che definisce come presentare valori di data e ora, fusi orari e scostamenti, durate e periodi in formati testuali specifici e non ambigui. Studia quella pagina Wikipedia ben scritta.
Nota in particolare ciò che lo standard chiama Durate
. Un intervallo di tempo è definito in questo formato:PnYnMnDTnHnMnS dove P significa "Periodo", il T separa la parte della data dalla parte dell'ora e le altre parti facoltative sono cifre + lettera. Un appuntamento di mezz'ora sarebbe PT30M . Questo potrebbe essere utile per te, ad esempio per il campo "period_" visualizzato nel mio ERD
sotto. In Joda-Time, la classe Period rappresenta un intervallo di tempo monitorando i suoi mesi, giorni, ore, ecc. e sa come analizzare e generare stringhe in questo formato.
Semiaperto
Puoi scegliere di memorizzare gli appuntamenti in uno dei due modi. Un modo è una data-ora di inizio e una durata (90 minuti, 20 minuti, ecc.). Un altro modo è registrare sia una data-ora di inizio che di fine. In questo caso, l'approccio usuale e generalmente migliore è chiamato "Half-Open". Ciò significa che l'inizio è inclusivo mentre il finale è esclusivo .
Ad esempio, un appuntamento di un'ora all'ora va dalle 11:00 alle 12:00, il che significa "a partire dalle 11:00 e fino al primo momento dell'ora successiva (mezzogiorno) ma non compreso". Il prossimo appuntamento sarà dalle 12:00 alle 13:00.
Cerca in StackOverflow "Half-open" per trovare altre discussioni, esempi e diagrammi.
Molti a molti
La relazione tra Paziente e Dottore è ciò che chiamiamo Many-To-Many . Un medico vede molti pazienti e un paziente può vedere più di uno dei medici. Assicurati di conoscere le tabelle Many-To-Many nella progettazione di database relazionali. La soluzione è sempre aggiungere una terza tabella, a volte chiamata tabella "bridge" che funge da tabella figlio per entrambe le altre tabelle padre. Nel tuo caso, l'Appuntamento table è il tavolo bridge.
Avrai bisogno di sapere come eseguire i join in una relazione molti-a-molti.
SQL diretto
Se sei nuovo nella programmazione o nuovo nel database relazionale, ti suggerisco di evitare Hibernate. Dovresti davvero capire cosa sta succedendo. Hibernate ha alcuni usi appropriati. Ma se pensi che Hibernate farà sparire magicamente i problemi del database, rimarrai deluso.
Attributi
Gli attributi dipendono da te. Dipendono dal problema aziendale (o dai compiti?) che stai cercando di risolvere. Hai le basi giuste.
La pianificazione degli appuntamenti è un problema aziendale molto difficile per il quale scrivere software. Ad esempio, stai semplicemente registrando gli appuntamenti presi? Oppure stai monitorando la disponibilità dei medici, creando fasce orarie predefinite e, in caso affermativo, come gestisci le eccezioni e le modifiche al calendario di ciascun medico? È necessario scrivere requisiti e casi d'uso molto specifici. Molto facile per le aspettative degli utenti superare i tuoi presunti requisiti.
Ecco una visione semplicistica.
