СержБыла давно такая идея... придумать модель универсального справочника, сделать для него универсальную форму ввода/выбора/поиска...

Вошли в штопор на первом же этапе -- дать определение понятию СПРАВОЧНИК. Придумали много, но почти все реальные сущности, которые мы НАЗЫВАЛИ справочниками под придуманные определения не подходили.

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

Возникает ощущение, что некоторые не избавились от хм... страстного желания унификации. Т.е. если две совершенно разные сущности имеют атрибут ИМЯ, то нужно обязательно им выделить общего предка и вынести туда этот атрибут (т.е. положить все на одну таблицу). Как правило, при таком подходе приложение начинает разрываться внутренними связями и рушится.

Если две сущности имеют одинаково произносимые атрибуты , это еще не означает их родственность. И как правило есть совершенно разные сущности (классы, таблицы) с одинаково звучащими именами атрибутов/методов.

Мне лень искать примеры... но возьмем класс TFileStream и TForm из VCL, у них у обоих есть метод Close. И что, по этой причине дать им общего предка? Аналогичная ситуация со свойствами Checked, SelectedIndex -- оно есть у многих, но общего предка с этим свойством нет.
Я привел пример из VCL, но разницы с таблицами в данном случае нет.

Здесь приводили пример со 190 справочниками... Мне интересно... они что действительно все имеют только два атрибутама (ИД, ИМЯ) и никаких других отличий?
Может в данном случае это действительно ОДНА сущность с тремя атрибутами (ИД, ИМЯ, ТИП)?
Тогда и вопросов нет... Если же справочник товаров разделять на носки и топоры, то тогда и 2000 справочников может быть.

Пример SYSOBJECT из mssql, как довод за "все в одном" совершенно некорректен в данном случае. Это тот случай, когда именно так и должно быть. Если представить эту структуру графически, то это будет дерево классов, порожденных от общего предка ОБЪЕКТА БД. У всех у них очень много общего и над всеми ими производятся общие однотипные операции. Это обычный способ отображения дерева классов на ER-структуру -- общий предок с максимумом возможных полей находится в одной таблице, очень специфическое потомков выносится в дочерние таблицы.
Еще очень важно в этом примере то, что все объекты БД имеют ссылки друг на друга. Если представить их все в виде отдельных таблиц, то они будут иметь связи "все со всеми". Отображение на одну таблицу позволяет избавиться от этой гирлянды связей. И "гулять" по такой структуре намного легче, потому что много связей между объектами.

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

Остается вопрос и будущего. Даже если сейчас есть 100 справочников структуры (ИД, Имя), то где гарантия, что завтра у сотого не появятся особенности? И тут лучше сегодня иметь 100 таблиц, 4 хр. процедуры на insert/update/delete/select и 3 окошка для отображения/выбора/изменения.
Завтра, когда изменится табличка за номером 100, я добавлю ( в самом тяжелом случае ) еще 4 хп, 3 окошка, и не нужно будет ломать голову как втиснуть новые требования в старую структуру .

Еще мерещится вопрос разработки... Если у меня 190 таблиц в ЕрВине, они все разные... И когда от одной из них тянется связь, я точно знаю, от какой. Если же у меня одна чудо-таблица, то все связи идут от одной таблицы... И что потом по такой структуре можно понять??? С чем именно связаны таблицы "Заказ--Состав заказ", с валютой, с единицой измерения, товаром??? Все связи будут тянуться к одной таблице (все в одном).
И что в таком случае делать с ограничениями целостности? Ведь где-то правило будет restrict, где-то set to null...

---

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

Утверждения, типа "все в одном просто лучше множества таблиц" обнаруживает непонимание самих основ программирования.

P.S. Все таки интересно посмотреть на перечень 190 справочников только из двух полей.

Зря Вы это. Использование унификации, аналогий, симметрии и других концепций крайне полезно при проектировании. И при чем здесь основы программирования? Вы стараетесь программировать (больше программировать) или, наоборот, не программировать (меньше программировать)?

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

Что касается именно "справочников" (теперь понятно, что "товары" - это не справочник!) и "похожее - вместе, различное - отдельно", то я храню, конечно, даже "абсолютно похожие справочники" в разных таблицах. Иначе говоря, разные сущности я храню в разных таблицах.
Справочник видов оплат и справочник видов транспорта я не объединю даже, если в них никогда не добавится никаких атрибутов, кроме ID и Name.