Estets Серж
P.S. Все таки интересно посмотреть на перечень 190 справочников только из двух полей.
Например документооборот, у каждого документа есть признаки:

1-Внешний
2-внутренний

1-Входящий
2-Исходящий

1-Бумажный
2-Электронный

1-Передан по почте
2-Курьером
3-По сети

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

Это, скорее, домены, чем справоники. И лежать должны в доменах.

softwarerBelyУ нас для таких супер простых вариантов есть таблица SIMPLE_LIST, где есть поле NAME, ID, CATEG_NAME
Когда-то, году в 94-м, я работал примерно так же, на клиппере. Потом, когда пришел на Oracle, задал вопрос - а почему бы не сложить простые справочники таким манером. В ответ на что получил просьбу назвать хотя бы одно осмысленное преимущество такой вот "кучи малы" (под неосмысленными я понимаю, например, экономию нескольких килобайт дискового пространства). Попробовал - и не смог. Так до сих пор и не могу, одни минусы.

Выгода, собственно, одна - не требуется изменять структуру базы под каждый чих.
Так проще как клиентам, так и разработчику (как фирме, а не человеку), особенно если проходится поддерживать десяток-другой разных версий одного и того же продукта. Не надо морочиться со структурой базы при переносе кода из одной версии в другую, ибо и с кодом заморочек хватает. А добавлять подобные справочники приходится достаточно часто (порою в рамках фиксов/патчей), что бы для каждой такой мелочи дожидаться, скажем, релиза, в котором меняется структура базы. И, кстати, да. Самый распостраненный вариант использования таких справочников - EAV. А что делать? Говорит заказчик - хотим этот атрибут через неделю (в лучшем случае)! И что делать? Тащить изменение структуры через все пространства (разработка - тестовое - выпуск) за одну неделю? Не, я видал, конечно, таких героев, но вообще - в топку.
EAV имеет вои недостаки (точнее сказать - у него одни только недостатки), но все перекрывается одним достоинтством - скоростью добавления атрибутов.

Впрочем, мы уже спорили по этому поводу, но без особого успеха....

softwarerНиколай1Выгода, собственно, одна - не требуется изменять структуру базы под каждый чих.
Добавление справочника имеет смысл только тогда, когда на него кто-то будет ссылаться, а это в нормальном варианте - уже "изменение структуры базы". Итого, чтобы этот аргумент имел смысл, БД ещё и не должна использовать человеческих внешних ключей, подменяя их тем или иным "суперуниверсальным механизмом ссылок чего угодно на что угодно". А в этом случае становится довольно странно видеть "обычные таблицы", особенно если учитывать, что о скорости работы и удобстве написания бизнес-логики речи уже не идёт, а вот для добавления в них атрибутов "требуется изменять структуру базы под каждый чих".

Итого получаем, что аргумент имеет смысл только в рамках "общего универсального движка" или на прямом пути к нему. Плюсы и минусы такого подхода... изучены.

Религиозный подход фиксов-патчей-релизов я не совсем понял.

Гм. Что же в нем непонятного?
Есть большой продукт, который стоит у большого количества клиентов и регулярно (раз в месяц) централизовано обновляется (это, допустим, версия). Если надо сделать что-то срочное, то выпускается фикс. Срок его выпуска - 1 день.
Всего есть (упрощенно) три пространства - разработка, тестирование и выпуск. При нормальной разработке сначала все делается в пространстве разработки, потом результат переностится в пространство тестирования, потом - в выпуск.
При экстренных изменениях все сразу делается в пространстве выпуска, а потом возвращается "обратно" в разарботку и тестирование.
Еще есть десяток клиентов у которых есть свои, более другие, версии. Со своим зоопарком пространств (правда покороче).
Ну и представьте, какой объем работы надо будет проделать, если, вдруг, придется изменять структуру базы. Как минимум - это столько же, сколько делается при изменении кода (хотя что-то мне подсказывает, что больше). Ну и надо учесть, что баз обычно больше, чем пространств и достаточно часто практикуется переключение с одной базы на другую по мере надобности. "А теперь у них у всех - разная структура".

Что касается использования новых справочников, то я об этом уже писал - EAV. И, таки, да, движок. Добавляем классификатор (тот самый, универсальный), дополнительный атрибут и - телемаркет. Пользователь может работать. Если этот реквизит нужен только на экране и при печати, то ничего кодировать не нужно вообще. Если где-то еще, то надо написать это самое "еще".

Не понимаю, кстати, религиозных выпадов типа, "тогда все надо сложить в одну таблицу" или "тогда все в EAV". Зачем? В EAV попадает только то, что a) нужно срочно б) не требует никакой обработки, кроме ввода, отображения и печати. Остальное лежит в "обычных" таблицах.
Кстати, далеко не все данных из таких "справочников" сохраняются в базе. Некоторые могут использоваться исключительно для управления некими процессами. Например - операций экспорта/импорта, для указания соответствия внутренних и внешних кодировок.

Что же касается пресловутой "ссылочной целостности", то проблемы, порожденные ее отсутствием, составляют, хорошо если 5% от общего числа проблем приложения (из моей более чем 15 летней практики сопровождения тиражных продуктов).