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

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

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

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

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

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

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

BelyВсе это верно, если говорить о СПРАВОЧНИКЕ.
Читаем первое сообщение темы вплоть до уверенного ответа на вопрос "говорится ли там о справочниках"....?

BelyЛично я не вижу принципиальной разницы для программиста между запросами:



А я вижу. Разница в том, что запросы


будут быстро и эффективно исправлены, а вот


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

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

- для справочника X заводится категория "X" и дополнительное поле F_X
- в одном из запросов пишется where F_X = '12345' и при этом не делается проверки CATEGORY = 'X'
- это "правильно" работает из-за того, что "X" - единственная категория, в которой используется поле F_X
- через год для совсем другого модуля добавляется справочник-категория "Y", в которой также используют поле F_X
- "другой модуль" успешно проходит тестирование и клиентам едет вводящий его патч.

Что же до "полного комплексного тестирования после каждого чиха" - мне неизвестен вендор, который проводил бы его. Причем не из-за лени и халатности, а из-за стоимости.

BelyНеубедительно...
Ваше право.

BelyВ качестве плюса использования одной таблицы - могу сказать, что в одной таблице проще искать строку "по значению", нежели в нескольких.
А нафига такая операция? "В каком именно справочнике присутствует значение 'USD'"? Как-то не в состоянии представить потребность в таком запросе.

iscrafmв каком документе присутствует 'USD'...
А поподробнее, если не затруднит? У нас документы - это уже строки справочника?

iscrafmпостроить систему можно по разному.
Можно. Можно вообще положить всю БД в одну таблицу. И если коллега утверждает, что в этом есть некий цимес - пытаюсь выяснить, какой именно.