П-Л, по хранению предложу третий вариант - таки общие таблицы - но с поддержкой иерархии, чтобы проще было ориентироваться в пользовательском интерфейсе в куче констант...

Гришков МаксимП-ЛПрально коллеги говорят - разными таблицами
Почему? Зачем "плодить" сущности?
+1

Гришков МаксимП-Линтерфейс ввода/редактирования вполне можно одной унверсальной формой.
Можно, но придется извращаться - вопрос зачем усложнять себе жизнь?
Ну если не одной - то по крайней мере по количеству типов данных для значений справочников - но не более того... всю остальную информацию можно держать в метаданных самих справочников... "-" - функционал из исходников всё больше переезжает в БД - и это нужно сопровождать и поддерживать...

alexeyvgГришков МаксимЕдинственное, что можно получить из варианта хранения данных в разных таблицах - полный контроль целостности средствами БД. Больше я пока ничего не вижу
Да, только это. Других преимуществ не будет, это единственное.
Это единственное преимущество валится следующими вариантами реализации:

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

Проблема только одна: в поле "статус" могут попасть ид. из других справочников.

варианты решения:
а) идентификаторы разных "справочникам" выдёются из разных диапазонов. На поле "статус" вешается check-constraint с условием попадания ид. в диапазон.
б) в таблице справочнике заводится доп.поле: "вид справочника". "вид справочника" и "идентификатор значения" - альтернативный ключ или первичный ключ таблицы. Вместо поля "статус" "документы" заводим два поля "вид справочника для статуса" и "ид статуса". Вешаем внешний ключ по двум полям на общий справочник. Вешаем чек-констрейнт на поле "вид справочника для статуса" = <константа>.

Итог: "полный контроль целостности средствами БД". Вопрос: "А этого ли мы хотели?"

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

ТС, самый яркий пример для сравнения:
а) единая таблица для справочников - реестр Windows.
б) использование разных таблиц для справочников: использование ini-файлов, разбросаных по папкам приложений.

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

Особенности:
1. единый интерфейс пользователя
2. единое место хранения
3. единый интерфейс обмена/изменения данных: Select,update,delete

Само слово "единая" (особенно в России :)) не явдяется плюсом, но вы легко сформулируете, оцените и сравните с вариантом "разные таблицы":
"затраты на проектирование справочника",
"затраты на модификацию БД для схемы справочника",
"затраты на разработку польз.интерфейса для просмотра списка записей справочника, детальной информации по записи справочника и модификации значений справочника",
"затраты на перенос изменений в продуктив".

"-":
1) в сопровождении: ошибочный update без where - портит всю справочную систему. Но это же не повод все однотипные документы делить в таблицы по месяцам, чтобы случайно не проапдейтить все...

2) в хранении данных: целостность, сравнимая с вариантом "разные таблицы" требует чуть больших затрат на проектирование, чем просто "не даст удалить значение", но не более того... Вплоть до автоматической генерации и выполнения нужных DDL команд на БД при формировании нового справочника пользователем непосредственно в интерфейсе Ввшей программы :). Это можно сделать и для варианты "разные таблицы", но для разных таблиц эта реализация сложнее в разработке, а в зависимости от БД - ещё и в применении на практике.