softwarer OraNew2007Не могли бы вы подробнее аргументировать какие минусы хранения простых справочников в одной таблице, какие плюсы при создании множества простых таблиц-справочников именно для Oracle. Спасибо.
Oracle вряд ли отличается здесь от других сходных СУБД. Аргументация следующая:

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

2. При ссылке на "объединенный справочник" возникает опасность сослаться на запись другой категории - скажем, в поле "id валюты" внести id записи "Ботинки 46-го размера". Избавиться от этого эффекта можно только денормализацией и составным внешним ключом, включающим id категории. А такое решение - мусор и большие накладные расходы.

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

4. В любой код, работающий с "объединенным справочником", нужно не забывать добавлять фильтр по категории или напротив, заполнение поля категория. Можно уверенно утверждать, что если не использовать вспомогательных средств (например, view with check option), где-то такие проверки будут забыты. А если использовать - возникает вопрос, нафига эта общая таблица, если работаем с "отдельными".

5. Добавление новых полей и вообще изменение требований к конкретному справочнику повиснет дамокловым мечом, геморроем в каждом случае. Скажем, представьте себе, что один справочник нужно насадить на временную ось (добавить поля date_from - date_to со смыслом "в такой-то интервал времени название было таким-то), а другие - оставить как есть.

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

Здравствуйте уважаемый softwarer!
Мне захотелось по этому поводу привести один пример. Я в принципе согласен со всеми перечисленными доводами, и сам почти всегда так делаю. Но почему Microsoft использует таблицу sysobjects в SQL Server 2000, в которой хранятся разнотипные объекты, такие как таблицы, первичные ключи, ограничения уникальности, пользовательские функции, хранимые процедуры и т.д. ?

Ведь так в СИСТЕМНЫХ таблицах теоретически могут появиться неверные ссылки, например вместо ссылки на хранимую процедуру будет ссылка на первичный ключ.