Data-godzina to jedna wartość
Wartości daty i godziny są prawie zawsze śledzone w oprogramowaniu jako pojedyncze wartości. Technicznie rzecz biorąc, są one reprezentowane wewnętrznie jako liczba sekund/milisekund/mikrosekund/nanosekund od epoki .
Możesz chcieć przedstawić datę i godzinę osobno w interfejsie użytkownika, ale nie wewnętrznie.
Ponadto prawie na pewno powinieneś pomyśleć o strefach czasowych. Naiwni programiści często myślą, że mogą ignorować strefy czasowe, ale prawie na pewno spowoduje to później udrękę.
Zrozumieć sposób obsługi daty i godziny w bazie danych
Różne bazy danych inaczej obsługują datę i godzinę. Absolutnie ważne jest, aby czytać dokumenty, bawić się, eksperymentować i uczyć się dokładnie, jak działa Twoja baza danych.
Postgres ma doskonałą i rozsądną obsługę daty i czasu. Nawet jeśli korzystasz z innej bazy danych, zapoznaj się z doskonałą dokumentacją Postgres pod adresem date- typy danych czasu i funkcje data-czas (polecenia), aby dowiedzieć się o różnych kwestiach i o tym, co jest zdefiniowane przez standard SQL, a co jest charakterystyczne dla Twojej bazy danych.
Przechowuj globalnie, prezentuj lokalnie
Date-Time to zaskakująco śliski i skomplikowany problem. Jednym z kluczy do rozwiązania problemu jest praca w UTC . Przechowuj wartości daty i godziny w bazie danych (lub w plikach serializowanych lub komunikacji XML/JSON) w formacie UTC. Napisz większość logiki biznesowej w UTC, z wyjątkiem miejsc, w których ważna jest lokalna strefa czasowa, takich jak definiowanie „początku nowego dnia”.
Podczas prezentowania użytkownikowi użyj formatu ISO 8601 lub zlokalizuj do własnej strefy czasowej (lub oczekiwanej strefy czasowej). Wynika to z podstawowej idei internacjonalizacji/lokalizacji. W przypadku wartości tekstowych w kodzie używasz określonych ciągów kluczy. Podczas prezentacji w interfejsie użytkownika mapujesz te wewnętrzne ciągi na zlokalizowane (przetłumaczone) wartości tekstowe dla interfejsu użytkownika. Niektóre z datą i godziną:wewnętrznie UTC, lokalna strefa czasowa w interfejsie użytkownika.
Jedno zastrzeżenie:możesz chcieć również przechowuj lokalną datę i godzinę ze względu na historię. Zasady stref czasowych zmieniają się często i kapryśnie z powodu polityków i biurokratów. Baza danych stref czasowych oprogramowania może być nieaktualna. Możesz więc chcieć przechowywać to, co Ty lub użytkownik uważacie za określoną datę i godzinę wtedy . Ale nie polegaj na tym; określić i zapisać wartość UTC.
Wskazówka:Naucz się myśleć i czytać w ciągu 24 godzin. Twoje życie jako programisty/debuggera/sysadmina stanie się o wiele łatwiejsze i mniej podatne na błędy.
Joda-Time lub java.time
Klasy java.util.Date i .Calendar dołączone do Javy są bardzo kłopotliwe. Unikaj ich.
Zamiast tego użyj Joda-Time lub nowy pakiet java.time wbudowany w Javę 8 (inspirowany Joda-Time, zdefiniowany przez JSR 310).
Obie biblioteki używają formatów ISO 8601 jako domyślnych, zarówno do analizowania, jak i generowania ciągów.
ISO 8601
ISO 8601 to rozsądny standard określający sposób prezentowania wartości daty i czasu, stref czasowych i przesunięć, czasu trwania i okresów w określonych i jednoznacznych formatach tekstowych. Przestudiuj tę dobrze napisaną stronę Wikipedii.
Zwróć szczególną uwagę na to, co standard nazywa Czas trwania
. Zakres czasu jest zdefiniowany w następującym formacie:PnYnMnDTnHnMnS gdzie P oznacza „kropka”, T oddziela część daty od części czasu, a pozostałe części opcjonalne to cyfry + litera. Półgodzinne spotkanie to PT30M . Może to być dla Ciebie przydatne, na przykład w przypadku pola „period_” widocznego w moim ERD
poniżej. W Joda-Time klasa Period reprezentuje przedział czasu, śledząc jego miesiące, dni, godziny itd., i wie, jak analizować i generować ciągi w tym formacie.
Półotwarte
Możesz wybrać zapisywanie spotkań na dwa sposoby. Jednym ze sposobów jest data rozpoczęcia i czas trwania (90 minut, 20 minut itd.). Innym sposobem jest zapisanie zarówno daty i godziny rozpoczęcia, jak i zakończenia. W tym przypadku zwykłe i ogólnie najlepsze podejście nosi nazwę „Half-Open”. Oznacza to, że początek jest włącznie zakończenie jest wyłączne .
Na przykład jednogodzinne spotkanie o określonej godzinie będzie trwało od 11:00 do 12:00, co oznacza „rozpoczyna się o 11 rano i trwa do, ale nie obejmuje, pierwszego momentu następnej godziny (południa)”. Następne spotkanie odbędzie się od 12:00 do 13:00.
Wyszukaj w StackOverflow hasło „półotwarte”, aby znaleźć więcej dyskusji, przykładów i diagramów.
Wiele-do-wielu
Relacja między pacjentem i lekarz to nazywamy Wiele-do-wielu . Lekarz przyjmuje wielu pacjentów, a pacjent może odwiedzać więcej niż jednego lekarza. Upewnij się, że znasz tabele wiele-do-wielu w projektowaniu relacyjnych baz danych. Rozwiązaniem jest zawsze dodanie trzeciej tabeli, czasami nazywanej „pomostową”, która służy jako tabela podrzędna dla obu pozostałych tabel nadrzędnych. W Twoim przypadku Spotkanie tabela jest tabelą pomostową.
Musisz wiedzieć, jak wykonywać połączenia w relacji wiele-do-wielu.
Bezpośredni SQL
Jeśli jesteś nowy w programowaniu lub w relacyjnej bazie danych, sugeruję unikanie Hibernate. Naprawdę powinieneś zrozumieć, co się dzieje. Hibernate ma kilka odpowiednich zastosowań. Ale jeśli uważasz, że Hibernate w magiczny sposób sprawi, że problemy z bazą danych znikną, będziesz rozczarowany.
Atrybuty
Atrybuty zależą od Ciebie. Zależą one od problemu biznesowego (lub zadania domowego?), który próbujesz rozwiązać. Masz rację w zakresie podstaw.
Planowanie spotkań to bardzo trudny problem biznesowy, dla którego należy pisać oprogramowanie. Na przykład, czy po prostu nagrywasz umawiane spotkania? A może śledzisz dostępność lekarzy, tworząc predefiniowane przedziały czasowe, a jeśli tak, jak radzisz sobie z wyjątkami i zmianami w kalendarzu każdego lekarza? Musisz napisać bardzo konkretne wymagania i przypadki użycia. Bardzo łatwo dla oczekiwań użytkowników przekroczenie zakładanych wymagań.
Oto uproszczony widok.
