ASCRUSДоброго всем дня. На руках есть ТЗ с требованием, что система должна позволять динамически добавлять новые сущности без участия ИТ и перекомпиляции приложения. Требования к сожалению обоснованные, так как:
- Есть серия справочной информации с обязательно присутствующими полями Идентификатор и Наименование) и любым кол-вом дополнительных полей разных типов. Могут добавляться новые справочники и новые поля в существующих.
- Есть обьекты с набором обязательно присутствующих полей, любым кол-вом дополнительных полей разных типов, плюс ссылки, на какие записи справочников объект ссылается. Могут добавлятся как новые дополнительные поля, так и ссылки на справочники
- Есть формы сбора информации по обьектам, каждая форма ссылается на обьект и содержит в себе множество разделов, каждый из которых может содержать как информационные поля по состоянию обьекта (текстовые, числовые), так и поля по уточняющим значениям справочников, в которые обьект входит.
- Есть правила контроля (которые так же должны задаваться пользователями), которые должны проводить верификацию данных форм сбора информации и могут быть как простыми (к примеру поле больше чего то, поле не равно полю), так и сложными (к примеру сумма поля всех записей не должна превышать какого то числа или поле должно равняться сумме поля всех записей другой формы сбора информации по данному обьекту)
- Для полного счастья все это должно храниться в РСУБД в распределенном виде, то есть с многоуровневым распределением информации и ее движением посредством репликации, где справочники, обьекты и правила контроля двигаются сверху вниз, а формы сбора информации снизу вверх.

Задача нетривиальная и сложная с точки зрения ее применения на РСУБД. Буду признателен за мысли о подходах проектирования схемы БД. Пока на ум приходят следующие варианты:
1. Справочники лучше всего организовать в виде таблиц Типы справочников (Код типа, Наименование), Коды справочников (Код записи справочника, Наименование, Тип справочника), Типы аттрибутов справочников (метаструктура с определением имени, типа и формата значения аттрибута), Аттрибуты справочников (с полем varchar для хранения значения)
2. Обьекты можно хранить примерно по такой же схеме, как и справочники, то есть таблицы Обьекты (Код, прочие обязательные поля), Типы аттрибутов обьектов (метаструктура с определением имени, типа и формата значения аттрибута), Аттрибуты обьектов (с полем varchar для хранения значения) и Ссылки на справочники (Код обьекта, Код справочника)
3. Правила контроля можно привязать к алгоритмам, которые привязать к SQL процедурам
4. Вот с формами сбора информации полные непонятки - если описать таким же образом, как справочники и обьекты, то это печально отразится на разработке интерфейса ввода данных в них, который должен быть так же динамическим (то есть юзер сам рисует форму ввода данных) и легким (чтобы можно было массово вводить данные), так же возникнут проблемы с производительностью при проведении операций контроля данных и построении отчетности (запросы к таким структурам будут собираться огромными). Можно для таких форм и привязаться к DDL, создав таблицу Коды заполненных форм (Код, Код формы, Код Обьекта) и серию связанных на нее таблиц, которые автоматической генерацией DDL создаются и меняются при изменении в метаструктуре описания форм, где все равно придется динамически генерить запросы к данным таких форм, но будет высокая производительность и легкое построение форм ввода данных и отчетности. В качестве минуса такого подхода можно считать изменение структуры БД и изменение схемы подписки репликации, что означает необходимость репликации DDL команд с центральной БД на удаленные.

В любом случае мне кажется без собственной метаструктуры во первых не обойтись. Но вот хранить ли аттрибуты форм сбора информации вертикально (в виде КодАттрибута, Значение) или как обычно принято в реляционных БД - для меня вопрос вопросов и цена трудозатрат и рисков каждого из решений с учетом обьемов проекта может оказаться чрезвычайно высока при неправильном выборе.Вот здесь (п.3) и далее описано нечто подобное. Если есть вопросы, готов ответить

BelyКак решалась проблема изменения структуры? Собственно, основной вопрос этого топика :)Администратор системы может добавлять атрибуты и сущности либо через интерфейс системы, либо непосредственно средствами БД с последующим импортом изменений в репозитарий.