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

PVPВсе справочники в одной таблице. В общем, все они содержат относительно не много записей, поэтому эта таблица не растет на столько, что бы заметно было при выборках данных.
доводилось сталкиваться с таким подходом и есть замечания:
1. Как быть с внешними ключами? Если в большой таблице есть записи из нескольких справочников, то как на уровне СУБД ограничить ввод в таблицу данных значений из конкретного справочника? Можно конечно ставить диапазон, но будут проблемы с добавлением значений. Можно во внешний ключ ввести ещё дополнительное поле, но тоже как-то имхо некрасиво.
2. Засорение базы сотней мелких таблиц - это конечно плохо, но есть и плюс - все таблицы имеют свои собственные имена и их можно предсказать при переносе между системами. А в Вашем подходе какое имя будет у справочника если Вы его передадите в стороннюю систему?

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

стоит пожалуй более конкретно написать что не нравится в этом подходе,
а точнее попробую указать на несостоятельность преимуществ
PVP
Огромное преимущество - не засоряется база данных мелкими таблицами.
Например, только в одной Зарплате более сотни разных справочников.

в чём трудность хранения в базе 100-150 дополнительных таблиц, если не считать затрат на придумывание имён для этих таблиц? с именами конечно есть проблемы, но они достаточно легко разруливаются системными соглашениями.
PVP
Другое преимущество - элементарное добавление новых справочников в живой работающей системе, без остановки, без возни с исходными текстами и последующей перегенерации системы.

если в ТЗ на систему сразу стоит ограничение типа "должна быть возможность добавления новых справочников и создания документов, имеющих ссылки на эти справочники", то все перечисленные трудности не зависят от выбранного подхода. Выполнение одного CREATE TABLE никак не проблемнее чем INSERT INTO bigtable... и будет "возня с исходными текстами" или нет тоже лежит целиком на совести разработчика.
PVP
Третье преимущество - программисты сопровождения должны выучить одну таблицу и правила работы с ней - это происходит за полчаса.

... не только выучить одну таблицу, но и запомнить какие значения имеют одни и те же поля для разных справочников. А вот это уже никак не полчаса для "более сотни справочников". При наличии большого количества мелких таблиц с _одинковой_ общей частью на их освоение тоже уйдёт полчаса. А вот нестандартные дополнительные поля придётся учить и там и там.
PVP
Следующее - для ввода в данных в справочники и для выбора из них значений используется одна и та же функция - упрощение самой системы.

Вот тут поподробнее, пожалуйста - как функция ввода может совпадать с функцией выбора?! Вероятно имеется в виду некая функция пользовательского интерфейса, но это тоже детали...

Вобщем итоговое ИМХО - трудности, связанные с неоднозначностью интерпретации значения из большого мега-справочника, а именно ответ на вопрос "Какому под-справочнику принадлежит значение с кодом ХХХХ?", на мой взгляд перевешивают призрачные приимущества, которые указаны в качестве плюсов данного подхода.