@1099511627776
Пишу все что интересно и на всем на чем интересно

Какую структуру БД выбрать

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

1. Структура похожая на 1С, где отдельному типу документа соответствeуют 2 или более отдельных таблиц (1 для шапок документов и по одной на каждое из тел документов)

2. Структура похожая на Abills, где которая менее универсальна но (возможно) более быстра, в которой все шапки документов содержатся в одной таблице (DOCS), + все тела документов содержатся в другой таблице (REESTR).

Какая из этих структур более предпочтительна для организации программы учета.
  • Вопрос задан
  • 3465 просмотров
Пригласить эксперта
Ответы на вопрос 6
EugeneOZ
@EugeneOZ
ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0 — прочитайте про нормальные формы и выберите ту структуру, которая не нарушает хотя бы третью форму.

Разные сущности лучше хранить в разных таблицах. Однако те структуры 1С, которые я встречал, на мой взгляд очень избыточны. Есть вообще модель EAV — это полная задница.
Ответ написан
@quantum
Первая структура. Она и быстрее и гибче.

Нужно вам добавить атрибут в документ — добавит только в нужный, а не во все — это гибкость и экономия места.

Данные будут распределены по таблицам — это скорость выборки и вставки.
Ответ написан
Комментировать
@ztxn
>>Какая из этих структур более предпочтительна для организации программы учета.

Учет подразумевает еще и ведение каких-то преаггрегаций. Запасы, состояния счетов и пр пр.

В случае, когда используется первая структура, для каждого типа документов должна быть реализована своя собственаня процедура проведения по остаткам. В результате, пересчитать все остатки по документам или же выявить какими документам сформировался некий текущий остаток, оказывается достаточно проблемотично. Чтобы как-то унифицировать расчет остатка, упростить отслеживание того, как остаток формируется, придется лепить еще одну суррогатную сущность — проводку, для каждого из разрезов остатков. И ссылаться эта проводка будет на разные структуры данных, что очень не канонично, целостность стандартными средствами не проконтролируешь.

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

Я видел несколько систем, где транзакционные документы сохраняются в трех структурах. 1 — Документы с внешними контрагентами — документы купли/продажи 2) Внутренние документы — перемещения между складами/зонами внутри организации, изменение статуса товара, списания всяческие и пр. 3) Фискальные документы, сиречь чеки. Мне такой подход кажется наиболее подходящим для большинства задач, с которыми мне приходилось сталкиваться.
Ответ написан
png
@png
А можно вообще каждый столбец описать 3-я таблицами. тип данных, описание столбцов и значения столбцов.
Будет мега универсально, но как только придется делать отчет, то на каждый столбец придется писать подзапрос.
запросы при этом получатся трех-этажные.
Такой подход есть в redmine для настраиваемых полей. Видел так же его в некоторых корпоративных приложениях разного класса.

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

Для себя я бы выбрал что-то среднее и больше ориентировался на логику кода, которая должна быть независимой от структуры БД.
Ответ написан
@1099511627776 Автор вопроса
Пишу все что интересно и на всем на чем интересно
Спасибо за ответ
> Для себя я бы выбрал что-то среднее и больше ориентировался на логику кода, которая должна быть
> независимой от структуры БД.
В этом случае СУБД будет использоваться практически как книга excel
т.е практически никаких stored procedures. ну максимум пересчет регистров\аккумуляторов или вывод сальдо на дату и то не всегда
Ответ написан
Комментировать
@1099511627776 Автор вопроса
Пишу все что интересно и на всем на чем интересно
Прочитал третью нормальную форму. Ни одна из описанных структур не нарушает ее.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы