Здравствуйте!

Поделюсь своим опытом по этому вопросу.

В своё время *в 200-ом году) наши заказчики возжелали иметь у себя так называемую систему ведения справочников, т.е. отдельное приложение, которое в отдельной базе ведёт все справочники, которые используются в нескольких десятках учреждений.

Мы пошли по пути, который автор обозначил как SQL DDL.

Вот что из этого получилось (в общих чертах):

Структура справочников:
1. Термин справочник определён как набор объектов (таблиц, триггеров и т.д.), описывающих нечто из предметной области.
2. Внутри справочника выделили несколько типов таблиц:
- линейная таблица справочника - основная таблица справочника
- таблицы дополнительных свойств
- таблицы оглавлений, задающие иерархию для линейной таблицы
- ещё пара типов таблиц...
3. Для линейных таблиц справочников утвердили набор стандартных полей (код, наименование, период действия записи, дата создания записи). Всего таких служебных полей получилось 9 штук. Эти поля есть в каждой линейной таблице, их нельзя удалить и их порядок фиксирован.
4. Кроме служебных полей есть дополнительные поля (начиная с 10-го), которые можно добавлять/удалять по мере необходимости.
5. Среди дополнительных полей могут встречаться поля-ссылки, т.е. поля ссылающиеся на другие справочники.

Порядок работы самой программы:
1. Для хранения описательной информации сформирован набор из примерно 10 служебных таблиц (репозитарий), в которых хранятся данные о полных наименованиях объектов, списки полей (с дополнительными свойствами) и ещё много чего, что понадобилось для нормальной работы.
2. Рядовым действием системы является создания нового объекта (справочника, оглавления, поля, ...), а это значит, что выполняются соотвествующие DDL-команды (CREATE TABLE, ALTER TABLE, CREATE TRIGGER, ...). Соотвественно для таблиц есть интерфейс добавления/удаления полей/индексов/связей.
3. Для просмотра справочников испольется многооконный интерфейс и обычные гриды. Для редактирования записей приходится для каждой таблицы строить свою форму в виде a'la property editor в Delphi/C#/...

вот такая основная идея - будут вопросы, отвечу

с уважением,
Дмитрий Жучков

vinniPooh2 Dimkas
Не мог бы ты распространиться о скорости написания, работы и усилиях, необходимых для поддержки всего этого?

скорость написания - первая версия была написана за полгода в одиночку, но с первого раза ни работоспособность, ни функциональность заказчика не устроили и пришлось ещё месяца 3 дописывать/переписывать. А для достижения текущего результата понадобилось примерно 5 человеко лет ;)
т.к. сейчас и СУБД другая, и функций сильно больше...
vinniPooh
Что было особенно неприятно делать, какие подводные камни, что при таком подходе радовало?

Особо неприятно то что структура таблиц меняется на ходу,
когда раньше жили на MS SQL Server'е, то DDL-операции можно было включить в транзакцию и в случае чего откатить, сейчас живём на Oracle и приходится думать как сделать аккуратнее ибо откатить DLL уже нельзя...
Подводных камней особых не вспомню, хотя конечно были трудности...
Что порадовало - тоже особенно ничего не припомню :) работа как работа...
vinniPooh
Насколько я понимаю, при создании нового справочника модифицируются (добавление внешних ключей) также и те таблицы, которые ссылаются на этот справочник - для поддержания целостности?

При создании нового справочника на него ещё никто не ссылается, ведь его только что не существовало :). Вопрос надо уточнить...
vinniPooh
На какой базе это работало?

Сначала работало на MS SQL 97, потом MS SQL 2000, потом переехали на Oracle 8.1.7 и FireBird 1.5, сейчас качуем в сторону Oracle 10.2 и FireBird 2.0
vinniPooh
Так как у меня конкретная СУБД не определена, то боюсь, что могут возникнуть проблемы с мигрированием.

не понял, какие проблемы? мигрированием чего и куда?

vinniPooh После того, как справочник создан, на него могут ссылаться другие таблицы. Прописывали ли вы явно в других таблицах внешние ключи на этот справочник? Или целостность поддерживалась каким-то другим образом?

Да, внешние ключи прописываются при добавлении в справочник поля, ссылающегося на другой справочник.
Периодически администратор системы выполняет так называемую проверку целостности - проверяются все первичные и внешние ключи, наличие и правильность триггеров и т.д.
vinniPooh Посколько синтаксис SQL DDL может, к сожалению, быть различным для разных СУБД, а у меня целевая СУБД не определена или может меняться (пути кастомера неисповедимы), теоретически могут возникнуть проблемы с переходом с одной базы на другую.
теперь понял :) у нас система работает на двух разных базах (Oracle и FireBird).
естественно, что для них запросы строятся разные. для этого введён промежуточный программный слой, которому приложение сообщает что надо сделать, а он уже делает... вобщем то всё как обычно...