powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование planner'а: нужен совет
27 сообщений из 27, показаны все 2 страниц
Проектирование planner'а: нужен совет
    #38081774
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Понадобилось прикрутить к базе расписание приема пациентов, причем клиник может быть несколько. Набросал примерно такую схему

DDL
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
/******************************************************************************/
/***                                Domains                                 ***/
/******************************************************************************/

CREATE DOMAIN DMN_BLOBTXT AS
BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET UTF8;

CREATE DOMAIN DMN_BOOL AS
SMALLINT
DEFAULT 0
NOT NULL
CHECK (VALUE IN (0,1));

CREATE DOMAIN DMN_DATE AS
DATE
DEFAULT CURRENT_DATE
NOT NULL;



/******************************************************************************/
/***                                 Tables                                 ***/
/******************************************************************************/



CREATE TABLE TBL_CLINIC (-- табля с клиниками 
    ID_CLINIC    INTEGER NOT NULL,
    NAME_CLINIC  VARCHAR(100) CHARACTER SET UTF8 NOT NULL
);

CREATE TABLE TBL_DOCTOR (-- табля с докторами
    ID_DOCTOR   INTEGER NOT NULL,
    FIO_DOCTOR  VARCHAR(100) CHARACTER SET UTF8 NOT NULL
);

CREATE TABLE TBL_PATIENTS_GENERAL (-- пациенты с оформленной амб.картой
    ID_PATIENTS_GENERAL   INTEGER NOT NULL,
    FIO_PATIENTS_GENERAL  VARCHAR(100) CHARACTER SET UTF8 NOT NULL
);

CREATE TABLE TBL_PATIENTS_TEMP (-- пациенты без оформленной амб.карты
    ID_PATIENTS_TEMP   INTEGER NOT NULL,
    FIO_PATIENTS_TEMP  VARCHAR(100) CHARACTER SET UTF8 NOT NULL
);

CREATE TABLE TBL_PLANNER (-- табля расписания
    ID_PLANNER           INTEGER NOT NULL,
    FK_DOCTOR            INTEGER NOT NULL,
    FK_CLINIC            INTEGER NOT NULL,
    FK_ROOM              INTEGER NOT NULL,
    FK_PATIENTS_GENERAL  INTEGER NOT NULL,
    FK_PATIENTS_TEMP     INTEGER NOT NULL,
    DATE_PLANNER         DMN_DATE,
    NOTES_PLANNER        DMN_BLOBTXT
);

CREATE TABLE TBL_ROOM (--табля кабинетов
    ID_ROOM    INTEGER NOT NULL,
    NUMB_ROOM  INTEGER,
    NAME_ROOM  VARCHAR(20) CHARACTER SET UTF8 DEFAULT 'Unnamed Room' NOT NULL
);

CREATE TABLE TBL_TIME_SLICE (--табля интервалов
    ID_TIME_SLICE   INTEGER NOT NULL,
    FK_PLANNER      INTEGER NOT NULL,
    TIME_SLICE_300  DMN_BOOL,
    TIME_SLICE_310  DMN_BOOL,
    TIME_SLICE_320  DMN_BOOL,
    TIME_SLICE_340  DMN_BOOL,
    TIME_SLICE_350  DMN_BOOL,
    TIME_SLICE_360  DMN_BOOL,
    TIME_SLICE_370  DMN_BOOL,
    TIME_SLICE_380  DMN_BOOL    
);



/******************************************************************************/
/***                              Primary Keys                              ***/
/******************************************************************************/

ALTER TABLE TBL_CLINIC ADD CONSTRAINT PK_TBL_CLINIC PRIMARY KEY (ID_CLINIC);
ALTER TABLE TBL_DOCTOR ADD CONSTRAINT PK_TBL_DOCTOR PRIMARY KEY (ID_DOCTOR);
ALTER TABLE TBL_PATIENTS_GENERAL ADD CONSTRAINT PK_TBL_PATIENTS_GENERAL PRIMARY KEY (ID_PATIENTS_GENERAL);
ALTER TABLE TBL_PATIENTS_TEMP ADD CONSTRAINT PK_TBL_PATIENTS_TEMP PRIMARY KEY (ID_PATIENTS_TEMP);
ALTER TABLE TBL_PLANNER ADD CONSTRAINT PK_TBL_PLANNER PRIMARY KEY (ID_PLANNER);
ALTER TABLE TBL_ROOM ADD CONSTRAINT PK_TBL_ROOM PRIMARY KEY (ID_ROOM);
ALTER TABLE TBL_TIME_SLICE ADD CONSTRAINT PK_TBL_TIME_SLICE PRIMARY KEY (ID_TIME_SLICE);


/******************************************************************************/
/***                              Foreign Keys                              ***/
/******************************************************************************/

ALTER TABLE TBL_PLANNER ADD CONSTRAINT FK_TBL_PLANNER_1 FOREIGN KEY (FK_DOCTOR) REFERENCES TBL_DOCTOR (ID_DOCTOR);
ALTER TABLE TBL_PLANNER ADD CONSTRAINT FK_TBL_PLANNER_2 FOREIGN KEY (FK_CLINIC) REFERENCES TBL_CLINIC (ID_CLINIC);
ALTER TABLE TBL_PLANNER ADD CONSTRAINT FK_TBL_PLANNER_3 FOREIGN KEY (FK_ROOM) REFERENCES TBL_ROOM (ID_ROOM);
ALTER TABLE TBL_PLANNER ADD CONSTRAINT FK_TBL_PLANNER_4 FOREIGN KEY (FK_PATIENTS_GENERAL) REFERENCES TBL_PATIENTS_GENERAL (ID_PATIENTS_GENERAL);
ALTER TABLE TBL_PLANNER ADD CONSTRAINT FK_TBL_PLANNER_5 FOREIGN KEY (FK_PATIENTS_TEMP) REFERENCES TBL_PATIENTS_TEMP (ID_PATIENTS_TEMP);
ALTER TABLE TBL_TIME_SLICE ADD CONSTRAINT FK_TBL_TIME_SLICE_1 FOREIGN KEY (FK_PLANNER) REFERENCES TBL_PLANNER (ID_PLANNER);
COMMIT WORK;

картинка

Все крутится вокруг табли (TBL_TIME_SLICE) с интервалами времени (столбцы в минутах от полуночи), каждую запись которой планирую отображать в сетке "девкинского" шедулера

Что смущает:
1. если брать 5-минутный интервал, то таких полей потенциально может быть 5 х 12 х 24 = 1440 - не широковата ли таблица?
2. нет ли тут избыточной нормализации в контексте подхватывания индексов и "многоэтажности" запросов?

Что и где "в консерватории подправить"?

=================
Док.

FB 2.5.2 26539, диалект 3, SS(многопольз.), FIB+ 7.4, DXE/IBExpert
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38082902
Mr.Fontaine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я иногда посещаю поликлиники и заметил, что разным докторам даётся разное время приёма пациента. У Вас чё-то такого не заметил. или я что-то не понял про интервалы.

Непонятно почему в таблице planner два пациента на одной записи. один doctor может принять сразу двух пациентов с картой и без карты? А двух пациентов с картами никак не получится?

Ну и почему room существуют отдельно от clinic. насколько я понимаю, кабинет №25 может присутствовать во всех клиниках, причём в первой он будет лабораторией, во втором хирургическим кабинетом, в третьем вообще санитарной комнатой.

А у докторов только ФИО? специальности врачам не требуются? Все универсалы? Если стомалога отправят в офтальмологию, он там сможет принять пациентов? Интересно что он там делать будет? В в кабинете окулиста стоят бормашинки или он будет пытаться указкой тыкать в табличку с буквами?
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38083165
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr.Fontaine,
вы про детали, а мне нужна концепция. Эта схема - грубый набросок, не более того ... По сабжу мысли есть?
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38083175
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, по поводу tbl_patients_temp (лишняя) и tbl_room (без FK на Tbl_Clinic) согласен ...
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38083305
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ДокMr.Fontaine,
вы про детали, а мне нужна концепция. Эта схема - грубый набросок, не более того ... По сабжу мысли есть?
По сабжу таблица интервалов должна, конечно, выглядеть (ID_Planner, ID_Time_slice, Value(?))
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38083403
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> если брать 5-минутный интервал

Откуда вдруг он у вас появился, не поясните?

Приходит в голову единственный разумный вариант: нормативное время приема любого специалиста кратно пяти минутам. Ну... как бы сильно вряд ли это имеет место, нет?

> Что и где "в консерватории подправить"?

Если для вас принципиальны интервалы (хотя, в общем, в целесообразности их использования в таком виде есть сомнения), вы можете развернуть таблицу. Расписание приема - ссылки на нее, прием - ссылки на расписание с учетом даты.

Знаете, есть какое-то внутреннее предубеждение против постановки задачи таким образом: на первый взгляд, она может быть корректной, но идеологически выглядит безобразно.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38083485
Mr.Fontaine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Концепции говоришь нету? Так-то на столбцы время ваще не стоит разбивать. Достаточно хранить просто время начала приёма и длительность приёма. Про длительность вообще нигде ничего не сказано

P.S. И что такое сетка "девкинского" шедулера?
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38083547
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr.Fontaine,
При Вашей структуре прием не может быть "разрывным" - не факт что это нужно отражать, но изначальная схема это позволяет делать.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38084006
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинПо сабжу таблица интервалов должна, конечно, выглядеть (ID_Planner, ID_Time_slice, Value(?))
ОК, прикину
guest_20040621Откуда вдруг он у вас появился, не поясните?
Изначально задумывалось, что интервалы со "своей" строкой в сетке, принадлежащие одному врачу и пациенту, должны были на уровне гуев объединяться (цветом или рамкой). Про "идеологическое безобразие" согласен - самому не нравиться.
Mr.FontaineP.S. И что такое сетка "девкинского" шедулера?
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38084196
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> на уровне гуев объединяться (цветом или рамкой)

Хозяин - барин. Можно просто: таблица интервалов нужной длительности (за час), таблица часов в сутках, сочетания - 288 интервалов. Бонус - удобно задавать время работы специалистов и клиник. Кривовато, но работоспособно.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38084310
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Можно просто: таблица интервалов нужной длительности (за час), таблица часов в сутках, сочетания - 288 интервалов.
Блин, самое очевидное всегда лежит на самом видном месте, потому и не видно, пока не абстрагируешься :)

Спасибо.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38086727
Mr.Fontaine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин, :-)
Я, наверное, недостаточно часто хожу по врачам, чтоб знать, что приём врача пациентом может осуществляться на перерывом на обед. Я такого никогда не встречал. И даже не слышал. Мне почему-то всегда дают талончик, в котором указано только одно время. Если мне требуется дважды прийти, то мне дают две бумажки, поэтому это, скорее всего, два разных приёма.

P.S. Хотя не исключено, что я что-то не понимаю в медицинском учёте.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38086753
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr.Fontaine,

Бывает прием по такой схеме - врач принимает пациента, отправляет его на, скажем, флюорографию и пока тот ходит, принимает следующего. Когда флюорография готова - пациент возвращается и прием продолжается. Не уверен что это можно отразить в учете как 2 приема.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38087661
Mr.Fontaine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Аналогично. Не уверен, что регистратура способна запланировать подобный приём и отправить пациента сразу к врачу и на флюорографию. Потому спорить думаю не о чем.
Согласен, что подобные возможности следует учесть и вариант топикстартера в этом плане лучше, чем мой.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38089153
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В первую очередь, я бы посоветовал тщательнее вкопаться в постановку задачи. Там будет энное количество сюрпризов, скажем пример из жизни: в кабинете физиотерапии есть две кушетки, два аппарата электросна, один аппарат электрофореза и один аппарат уж не помню чего. То есть, с одной стороны, кабинет запросто принимает двоих пациентов одновременно, с другой - пациент вынужден ждать, пропуская более поздних, пока освободится "его" аппарат.

Насколько я видел, "разрывными приёмами" нигде не заморачиваются. Чаще всего пациенту говорят "получите результаты и запишитесь повторно", в редких случаях - второй раз принимают без записи, пользуясь оставленными по нормативам резервами и времени и чуть сдвигая следующего.

С точки зрения структуры базы главную и имхо критическую проблему подхода я вижу в том, что "вообще вся база" оказывается завязана на мелкую и вариативную деталь бизнес-логики. Захотелось отображать картинку "в другом разрешении" - и всё, сущи вёсла, начиная с переделки базы и хранимок. Поэтому хочется спросить - а зачем вообще эти припрыжки, кто мешает хранить интервал как интервал, from/to? Разворачивать матрицу для календаря легко сможет хранимка - уж в Firebird с этим проблем быть не должно. Чуть пострадают декларативные проверки целостности, но их можно сделать в процедурах вставки, да и на клиенте контроль будет наглядным. Зато за счёт сокращения количества данных и улучшения структуры.. думаю, общее качество повысится.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090073
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за высказывания. Я пришел к следующему выводу:
1. Поскольку планируется отображать расписание в шедулере совершенно конкретного компонента (cxScheduler), то и структура базы будет регламентирована именно этим компонентом
2. Согласно п.1, время приема определяется банально двумя датами (старт и финиш), поэтому нет смысла городить огород с интервалами
3. данные в сетке шедулера логически группируются по дате и субъекту (кабинет, кушетки в кабинете, доктора), вот именно эти сущности и имеет смысл выделять в отдельные табли, делая ФК на них в основной табле планнера

Как-то так...
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090097
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Док,

так называемый шедулер (впридачу и гант) девок - говно полное
не советую пользоваться
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090100
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Док1. Поскольку планируется отображать расписание в шедулере совершенно конкретного компонента (cxScheduler), то и структура базы будет регламентирована именно этим компонентом
RIP.
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090240
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosне советую пользоваться
есть достойная альтернатива, кроме своего велосипеда?
softwarerRIP
в смысле, покойся с миром? ;)
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090285
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Док,

мой велоспиед то как раз самая достойная альтернатива многим вещам
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090292
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosмой велоспиед
и он раздается всем желающим бесплатно и по первому требованию? ;)

зы. Ганнт нарисован на обычной сетке?
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090294
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Док,

1. ниче не раздается (да и девки бесплатно не дают обычно)
2. что означает - "обычная сетка"? :)
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090302
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
есть и другие ганты
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090381
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRos2. что означает - "обычная сетка"? :)
стринггрид, дбгрид?
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090433
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Док,

слева грид или дерево (девок в данном случае, а так пофиг), справа панель
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38090488
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ДокsoftwarerRIP
в смысле, покойся с миром? ;)
Именно. У меня в этом несколько экстремальная позиция, подобное тесное связывание я считаю заведомой ошибкой, а уж "проектирование сервера исходя из текущих нужд криента"... блин, это была честная опечатка, но уж очень в тему
...
Рейтинг: 0 / 0
Проектирование planner'а: нужен совет
    #38091067
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerИменно. У меня в этом несколько экстремальная позиция, подобное тесное связывание я считаю заведомой ошибкой, а уж "проектирование сервера исходя из текущих нужд криента"... блин, это была честная опечатка, но уж очень в тему
Это где я такое написал?

зы. в последнее время я стал спокойнее относиться к изменению структуры БД ("... ну, подумаешь - укол! Укололся: и пошел ..."). Надеюсь, если понадобится, то без больших трудозатрат разобью поля с датами на master-detail.

А все остальное: нету там жесткой взаимосвязи с девкинским компонентом. Есть поля, отвечающие за ту или иную сущность (заголовок, мемо-поле, приоритет и проч.проч.), которые тот шедулер использует. Так их можно и в собственно гриде использовать ;)

Вобщем, у меня осталась одна дилемма: что использовать Unbound mode или Bound mode.
...
Рейтинг: 0 / 0
27 сообщений из 27, показаны все 2 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование planner'а: нужен совет
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]