Дата-час е една стойност
Стойностите за дата и час почти винаги се проследяват в софтуера като единични стойности. Технически те са представени вътрешно като брой секунди/милисекунди/микросекунди/наносекунди от епоха .
Може да искате да представите дата и час отделно в потребителския интерфейс, но не и вътрешно.
Освен това почти сигурно трябва да мислите за часовите зони. Наивните програмисти често си мислят, че могат да игнорират часовите зони, но това е почти сигурно, че ще причини мъка по-късно.
Разберете как вашата база данни работи с дата-час
Различните бази данни обработват датата и часа по различен начин. Абсолютно важно е да четете документите, да играете, да експериментирате и да научите как точно работи вашата база данни.
Postgres има отлично и разумно боравене с дата и час. Дори ако използвате друга база данни, консултирайте се с отличната документация на Postgres на date- типове данни за времето и функции за дата-време (команди), за да научите за различните проблеми и какво е дефинирано от SQL стандарта спрямо характерното за вашата база данни.
Съхранявайте глобално, представяйте локално
Дата-час е изненадващо хлъзгав и сложен проблем. Един от ключовете за задържане на проблема е да работите в UTC . Съхранявайте вашите стойности за дата и час в базата данни (или в сериализирани файлове, или XML/JSON комуникации) в UTC. Напишете по-голямата част от вашата бизнес логика в UTC, освен когато местната часова зона има значение, като например дефинирането на „началото на нов ден“.
Когато представяте на потребителя, или използвайте формат ISO 8601, или локализирайте в тяхната собствена часова зона (или часовата зона, която очакват). Това следва основната идея за интернационализация/локализация. За текстови стойности използвате определени ключови низове във вашия код. При представяне в потребителския интерфейс вие съпоставяте тези вътрешни низове с локализирани (преведени) текстови стойности за потребителския интерфейс. Някои с дата-час:вътрешно UTC, местна часова зона в потребителския интерфейс.
Едно предупреждение:Може да искате също съхранявайте местна дата и час в името на историята. Правилата за часовата зона се променят често и капризно заради политици и бюрократи. Базата данни за часовите зони на вашия софтуер може да не е актуална. Така че може да искате да съхраните това, което вие или потребителят смятате за определена дата-час след това . Но не разчитайте на това; определя и съхранява стойността на UTC.
Съвет:Научете се да мислите и четете за 24 часа. Животът ви като програмист/дебъгер/сисадмин ще стане много по-лесен и по-малко податлив на грешки.
Joda-Time или java.time
Класовете java.util.Date и .Calendar, свързани с Java, са изключително обезпокоителни. Избягвайте ги.
Вместо това използвайте или Joda-Time или новия java.time пакет вграден в Java 8 (вдъхновен от Joda-Time, дефиниран от JSR 310).
И двете библиотеки използват ISO 8601 формати по подразбиране, както за синтактичен анализ, така и за генериране на низове.
ISO 8601
ISO 8601 е разумен стандарт, определящ как да се представят стойности за дата и час, часови зони и отмествания, продължителност и периоди в специфични и недвусмислени текстови формати. Проучете тази добре написана страница в Уикипедия.
Обърнете внимание по-специално на това, което стандартът нарича Продължителности
. Период от време се дефинира в този формат:PnYnMnDTnHnMnS където P означава "Период", T разделя частта за дата от частта за час, а другите незадължителни части са цифри + буква. Половинчасовата среща би била PT30M . Това може да е удобно за вас, като например за полето „period_“, което се вижда в моя ERD
По-долу. В Joda-Time класът Period представлява период от време, като проследява неговите месеци, дни, часове и т.н. и знае как да анализира и генерира низове в този формат.
Полуотворено
Можете да изберете да съхранявате срещи по един от двата начина. Един от начините е начална дата-час и продължителност (90 минути, 20 минути и т.н.). Друг начин е да запишете както начална, така и крайна дата и час. В този случай обичайният и като цяло най-добрият подход се нарича "Полуотворен". Това означава, че началото е включително докато краят е изключителен .
Например, едночасова среща в часа ще продължи от 11:00 до 12:00, което означава „започвайки в 11 часа сутринта и до, но не включително, първия момент от следващия час (обед)“. Следващата среща ще е от 12:00 до 13:00 часа.
Потърсете в StackOverflow „Half-open“, за да намерите още дискусии и примери и диаграми.
Много към много
Връзката между Пациент и Доктор е това, което наричаме Many-To-Many . Един лекар вижда много пациенти, а пациентът може да види повече от един от лекарите. Уверете се, че знаете за много към много таблици в дизайна на релационна база данни. Решението винаги е да добавите трета таблица, понякога наричана "мостова" таблица, която служи като дъщерна таблица към двете други родителски таблици. Във вашия случай, Среща таблицата е мостовата маса.
Ще трябва да знаете как да извършвате обединявания във връзка много към много.
Директен SQL
Ако сте нов в програмирането или нови в релационната база данни, предлагам да избягвате Hibernate. Наистина трябва да разберете какво се случва. Hibernate има някои подходящи приложения. Но ако смятате, че Hibernate магически ще накара проблемите с базата данни да изчезнат, ще бъдете разочаровани.
Атрибути
Атрибутите зависят от вас. Те зависят от бизнес (или домашна работа?) проблем, който се опитвате да разрешите. Имате право на основите.
Планирането на срещи е много труден бизнес проблем, за който се пише софтуер. Например, просто записвате ли назначените срещи? Или проследявате наличността на лекарите, като създавате предварително определени времеви интервали и ако е така, как се справяте с изключенията и промените в календара на всеки лекар? Трябва да напишете много специфични изисквания и случаи на употреба. Много лесно очакванията на потребителите да надхвърлят предполагаемите ви изисквания.
Ето един опростен изглед.
