База данных и даты с событиями

Доброго времени суток. Разрабатываю приложение для больницы в рамках личного использования в котором содержатся отделения, пациенты, данные и даты поступления и перевода. Как организовать чтобы можно было видеть через DBGrid при фильтрации между датами путь пациента? Например: пациент A поступил в терапевтическое отделение 01.02.2025. Был переведен в реанимацию 03.02.2025 (то есть с 03.02.2025 в терапевтическом отделении он перевелся, а в реанимации появился), далее 08.02.2025 он перевелся обратно в терапевтическое отделение и уже 12.02.2025 идет выписка (то есть в отделении реанимации 08.02.2025 перевод, а в терапевтическом с 08.02.2025 он снова появляется)? Сейчас реализовано только возможность отображение пациента в отделении между датами поступления и перевода/выписки. Правильно ли я понимаю, что требуется отдельная таблица с датами движения пациентов, отделений и ключ пациента, который связывает 2 таблицы? В 1 таблице ФИО, паспортная часть

0

krapotkin, может я чего-то не понимаю, но мой порядок удобен ведь. Благодаря наличию законченной строки имеется работающая фильтрация по отделениям и нахождение пациента в заданном промежутке. В случае если дробить каждое действие подобное будет невозможно. Плюс каждая строка это дата поступления и законченное действие в виде перевода/выписки/летального исхода, что сразу отображается. Если дата поступления не закрыта, то в программе пациент числится за отделением, которое было введено в последней строке. Прям строгий порядок действий и не требуется ведь - требуется именно отображение поступления в отделение и исход с датой этого события. Ну и на самой истории требуется дата поступления в стационар и выписка для итогового подсчёта койко-дней.
А про поле arrival думал - да, действительно, это будет работать. Только пока так и не придумал как сделать его присвоение. Если в первом случае ещё можно придумать, то на повторную госпитализацию сделать что-то вроде кнопки повторной госпитализации с присвоением +1 к полю arrival? При этом возможность дополнительного фильтра на протоколах для просмотра только текущей госпитализации - добавить данное поле и в таблицу протоколов

0

1) тема гласит, что ваш удобный вариант - не удобный
2) см. 1)

если чего-то непонятно, всегда есть возможность уточнять до посинения
фильтрация по отделениям - в чем проблема?
есть запись "поступил"
в ней очевидно должно быть какое-то поле - куда поступил.
ставим условие - все записи, у которых arrival из предыдущего поста = "куда поступил"
??

чем повторная госпитализация отличается от первичной?
только тем, что она повторная
можно это вычислить, если смотреть просто историю поступлений
но вдруг предыдущий случай с этим не связан
тогда есть смысл просто сделать поле "related_to" и туда пихать опять же код события первичного поступления

Добавлено через 4 минуты
действия по текущей госпитализация - все записи, у которых arrival_id = <указываем id поступления>
действия по исходной госпитализации - все записи, у которых arrival_id = related_to_id
все действия от исходной до текущей госпитализации - все записи, у которых related_to_id = текущему related_to_id плюс записи у который arrival_id = текущему related_to_id (записи исходной г.)

0

Сообщение от Varyag061 как в Access в типе даты и время сделать чтобы прописывалось время не 4:00:00, а 04:00:00 - не могу из-за этого адекватно реализовать время поступления и выписки

Вот тут не понял. Какие претензии к Access? У вас морда-то на чём-то другом, судя по ADOQuery и т.п.
Движение между датами — DataPos <= Date2 and DateVyb >= Date1.

0

krapotkin, по истечению времени в конечном итоге требуется на каждое событие своя строка. Для того чтобы в итоге адекватно отобразить все события по пациенту. Вот только возможно ли реализовать все пожелания через одну дату? Условно в таблице Date и в неё записывать и дату поступления, и дату перевода с выпиской? Плюс требуется при переводе пациента чтобы автоматически делалась запись в переводе из текущего отделения и поступлении в другом отделении с единой датой и временем

0

чтобы адекватно отобразить все события по пациенту, нужно как раз и вести общий список событий по пациенту
дата-время, событие
дата-время, событие
и т.д.
а для каждого типа событий можно вести отдельные дополнительные таблицы

0

Логично иметь такую структуру таблицы событий.
а) Id пациента
б) Дата время события
в) Тип события - (поступил, выписался, умер, проведена операция, взяты анализы и т.д.)
г) Ссылка на доп.инф. по событию (отд.таблица, в завис.от в)
д) Какие-то другие параметры

Добавлено через 5 минут
При этом, при вводе и коррекции этой таблицы, необходим контроль (зашита от дурака), чтобы не возникало абсурдных ситуаций, типа выписался, но ещё не поступил и т.д.

Добавлено через 2 минуты
То. что мы с krapotkin вам советуем - поверьте, это оптимальный вариант, другие решения приведут в конечном итоге к коллизиям и порче БД.

Добавлено через 13 минут
Уточню для ясности -
в) Здесь должен находиться Id (целое число) события из отдельной таблицы-справочника событий.
г) Здесь должен находиться Id (целое число) записи из таблицы данного типа событий.
д) Возможно, Id (целое число) отделения записи из таблицы-справочника отделений, в которое/из которого поступил пациент.

Если осуществляется перевод из отделения в отделение, то формируются 2 записи в таблице событий "переведён в другое отделение" и "переведён из другого отделения". С единой датой/временем, естественно. При этом помнить, что при коррекции одной из этих записей, нужно корректировать и другую.

Добавлено через 5 минут
Другой вариант при переводе - совместить это в одной записи события, но в этом случае будет немного сложнее извлекать данные для построения цепочки по пациенту, хотя это не критично.

0

Massaraksh7, вариант отличный - спору нет. Но возникает вопрос на который пока я не могу получить ответ. Самое основное помимо описания всех событий это фильтрация данных. То есть сейчас идет в одной строке дата поступления и дата выписки/перевода и так далее. На основе этого я использую фильтрацию различную: указываю текущую дату и у меня отображается кто сейчас находится в отделении, подсчёт койко-дней между двумя датами. Будет ли работать адекватно фильтрация при наличии только даты события? На неё так же потребуется завязать подобный код
То есть есть основная база с пациентами (1), есть таблица с движением пациента (связь через id) (2) и есть дата поступления (DataPos), дата перевода/выписки и так далее (DateVyb). При этом ещё отдельно прописан пункт по которому DateVyb может отсутствовать - удобно если пациент находится в отделении без события. Плюс в одной строке есть закрепление пациента между двумя этими датами на отделение.
Заключение: фильтрация идёт по отделению, между двумя датами есть 3 дата - текущая. Возможно ли реализовать подобное при наличии только даты события?

0

Сообщение от Varyag061 То есть есть основная база с пациентами (1), есть таблица с движением пациента (связь через id)

Не совсем так методологически. То, что вы называете основной базой с пациентами - это всего лишь справочник пациентов. А то, что вы называете "таблица с движением пациента" - это и есть главная таблица, от которой пляшется всё остальное.

Сообщение от Varyag061 ON Baza.id=Dvizh.id

Не может id одной таблицы сравниваться с id другой таблицы, поле надо назвать как-то по-другому, например

ON Baza.id=Dvizh.idpatient

Сообщение от Varyag061 Возможно ли реализовать подобное при наличии только даты события?

Да, конечно.

0

Massaraksh7, там не сравнение идёт, а сопоставление. То есть связь 2х таблиц идёт через поле id. Данных для сравнения между двух таблиц нет - они взаимодополняют друг друга. Все данные для сравнения идут из одной таблицы названной Dvizh

0

Я, к сожалению, не работал конкретно с базой Access, но во всех СУБД в таблицах именем Id обычно называют первичный уникальный автоинкрементный ключ, который никак не сопоставляется с Id других таблиц.

0

Massaraksh7, первичный уникальный ключ просто назван другим именем. Поэтому расхождения нет в этом
А как SQL запрос создать для сравнения между датами из одной строки на примере запроса выше?

0

Я лично с Dbgrid не работаю, и вам не советую. Составляю запросы на выборку минимально необходимых данных в память, там их обрабатываю, фильтрую, если нужно, и отображаю в Stringgrid. Уверен, это можно сделать и одним запросом. Но для этого нужно иметь конкретную структуру БД, и конкретный вид отображаемых данных.

0

Сообщение от Massaraksh7 Уверен, это можно сделать и одним запросом. Но для этого нужно иметь конкретную структуру БД, и конкретный вид отображаемых данных.

Золотые слова. Однако!

0

Сообщение от Massaraksh7 Не может id одной таблицы сравниваться с id другой таблицы, поле надо назвать как-то по-другому

Это почему же?

Сообщение от Massaraksh7 во всех СУБД в таблицах именем Id обычно называют первичный уникальный автоинкрементный ключ

Кто называет?

0

Сообщение от northener Это почему же?

"Можно всё, но зачем?" (с)

0

Когда вопрос ставится - имею ли я право называть поля как хочу? - да конечно, на здоровье.
Только сами потом и @ с ними.

Очень, крайне, неприлично часто мейнстримовые фреймворки или фичи подразумевают, что разработчик не только писатель, а еще читатель, и знает пару-тройку отраслевых стандартов.
В этом случае все справочники автоматически (магически) линкуются по ключам, подключаются разные там связи и т.д.
А еще следующий разработчик, которому выпала высокая честь разбираться в вашем продукте после вас, не тратит слишком много денег на проработку травм у психолога.

Поэтому таблицы называются по имени сущностей в мн.ч., ключевые поля обычно называются id, а ссылки на них - имя сущности в ед.ч. + _id
И жить становится полегче.

Но это, конечно, принижает креативность и не дает развернуться настоящему таланту с большой, как имена классов в делфи, буквы Т.

Добавлено через 1 минуту
P.S. ключ не обязательно автоинкрементный
Если БД любит реплицироваться, или подгружать данные из внешних источников, то хороший выбор - современные time-based GUIDs

1

Сообщение от iifat я-то работаю в Пенсионном фонде

какой регион ?

0