Datum a čas je jedna hodnota
Hodnoty data a času jsou v softwaru téměř vždy sledovány jako jednotlivé hodnoty. Technicky jsou interně reprezentovány jako počet sekund/milisekund/mikrosekund/nanosekund od epochy .
Možná budete chtít prezentovat datum a čas samostatně v uživatelském rozhraní, ale ne interně.
Téměř jistě byste také měli přemýšlet o časových pásmech. Naivní programátoři si často myslí, že mohou ignorovat časová pásma, ale je téměř jisté, že to později způsobí muka.
Pochopte, jak vaše databáze nakládá s datem a časem
Různé databáze zpracovávají datum a čas odlišně. Je naprosto zásadní, abyste si přečetli dokumenty, pohráli si, experimentovali a naučili se přesně, jak vaše databáze funguje.
Postgres má vynikající a rozumné zacházení s datem a časem. I když používáte jinou databázi, nahlédněte do vynikající dokumentace Postgres na datum- typy časových dat a funkce data a času (příkazy), abyste se dozvěděli o různých problémech a o tom, co je definováno standardem SQL a co je typické pro vaši databázi.
Globálně ukládat, prezentovat lokálně
Datum-čas je překvapivě kluzký a komplikovaný problém. Jedním z klíčů k udržení problému je práce v UTC . Uložte své hodnoty data a času do databáze (nebo do serializovaných souborů nebo komunikace XML/JSON) v UTC. Napište většinu své obchodní logiky v UTC, kromě případů, kdy záleží na místním časovém pásmu, jako je definování „začátku nového dne“.
Když prezentujete uživateli, použijte buď formát ISO 8601, nebo lokalizujte do jeho vlastního časového pásma (nebo časového pásma, které očekávají). To navazuje na základní myšlenku internacionalizace/lokalizace. Pro textové hodnoty používáte v kódu určité klíčové řetězce. Při prezentaci v uživatelském rozhraní namapujete tyto vnitřní řetězce na lokalizované (přeložené) textové hodnoty pro uživatelské rozhraní. Některé s datem a časem:UTC interně, místní časové pásmo v uživatelském rozhraní.
Jedno upozornění:Možná budete chtít také uložit místní datum a čas kvůli historii. Pravidla časových pásem se často a svévolně mění kvůli politikům a byrokratům. Databáze časových pásem vašeho softwaru může být zastaralá. Možná budete chtít uložit to, co jste vy nebo uživatel považovali za určité datum a čas pak . Ale nespoléhejte na to; určit a uložit hodnotu UTC.
Tip:Naučte se myslet a číst za 24 hodin. Váš život jako programátora/ladicího programu/systémového správce bude mnohem jednodušší a méně náchylný k chybám.
Joda-Time nebo java.time
Třídy java.util.Date a .Calendar spojené s Javou jsou notoricky problematické. Vyhýbejte se jim.
Místo toho použijte buď Joda-Time nebo nový balíček java.time zabudovaný do Java 8 (inspirovaný Joda-Time, definovaný JSR 310).
Obě knihovny používají jako výchozí formáty ISO 8601 pro analýzu i generování řetězců.
ISO 8601
ISO 8601 je rozumný standard definující, jak prezentovat hodnoty data a času, časová pásma a posuny, trvání a období ve specifických a jednoznačných textových formátech. Prostudujte si dobře napsanou stránku Wikipedie.
Všimněte si zejména toho, co standard nazývá Doby trvání
. Časové rozpětí je definováno v tomto formátu:PnYnMnDTnHnMnS kde P znamená "Období", T odděluje část data od části času a další volitelné části jsou číslice + písmeno. Půlhodinová schůzka by byla PT30M . To se vám může hodit, například pro pole „period_“ zobrazené v mém ERD
níže. V Joda-Time představuje třída Period časový úsek sledováním měsíců, dnů, hodin atd. a ví, jak analyzovat a generovat řetězce v tomto formátu.
Polootevření
Schůzky můžete ukládat jedním ze dvou způsobů. Jedním ze způsobů je datum zahájení a doba trvání (90 minut, 20 minut atd.). Dalším způsobem je zaznamenat datum a čas začátku i konce. V tomto případě se obvyklý a obecně nejlepší přístup nazývá „Half-Open“. To znamená, že začátek je včetně zatímco koncovka je výlučná .
Například hodinová schůzka v tuto hodinu bude probíhat od 11:00 do 12:00, což znamená „začíná v 11:00 a trvá až do prvního okamžiku další hodiny (poledne), ale bez něj“. Další schůzka bude probíhat od 12:00 do 13:00.
Vyhledejte ve StackOverflow "Half-open" a najděte další diskuzi, příklady a diagramy.
Mnoho-mnoho
Vztah mezi Pacientem a doktor je to, čemu říkáme Mnoho-mnoho . Lékař navštěvuje mnoho pacientů a pacient může vidět více než jednoho lékaře. Ujistěte se, že víte o tabulkách Many-To-Many v návrhu relační databáze. Řešením je vždy přidat třetí tabulku, někdy nazývanou "bridge" tabulka, která slouží jako podřízená tabulka k oběma ostatním nadřazeným tabulkám. Ve vašem případě Schůzka tabulka je tabulka mostu.
Budete potřebovat vědět, jak provádět spojení ve vztahu many-to-many.
Přímé SQL
Pokud s programováním nebo s relační databází teprve začínáte, doporučuji vyhnout se Hibernate. Opravdu byste měli mít přehled o tom, co se děje. Hibernace má některá vhodná použití. Ale pokud si myslíte, že Hibernate magicky odstraní problémy s databázemi, budete zklamáni.
Atributy
Atributy jsou na vás. Závisí na obchodním (nebo domácím úkolu?) problému, který se snažíte vyřešit. Základy máte správně.
Plánování schůzek je velmi obtížný obchodní problém, pro který psát software. Zaznamenáváte například pouze domluvené schůzky? Nebo sledujete dostupnost lékařů vytvářením předdefinovaných časových úseků, a pokud ano, jak řešíte výjimky a změny v kalendáři každého lékaře? Musíte napsat velmi specifické požadavky a případy použití. Očekávání uživatelů velmi snadno překročí vaše předpokládané požadavky.
Zde je zjednodušený pohled.
