s785Таким образом, можно сделать вывод, что так обзывать поля есть нормальная практика, не приводящая к серьёзным осложнениям в будущем?
Практика нормальная, никаких осложнений не предвидится.

Я поступаю несколько иначе - "широко распространенные" имена полей квалифицирую именем сущности, то есть organization_name, goods_qnt итп. Для меня это несколько удобнее, но причины в общем достаточно мелки - уровня того, что Вы назвали с NAME1.

TyoПри росте кол-ва справочников начнете забывать -- что в какой таблице.


TyoВедение справочников облегчается и формализуется.


TyoА если возникнут индивидуальные атрибуты -- прикрутите в доп. таблице, опять-таки одной на всех.
Cтранно, что Вы до сих пор не пришли к идее хранить всю базу в одной таблице. Или к EAV.

TyoСам использую именно такой.
Этот аргумент понятен.

BelyУ нас для таких супер простых вариантов есть таблица SIMPLE_LIST, где есть поле NAME, ID, CATEG_NAME
Когда-то, году в 94-м, я работал примерно так же, на клиппере. Потом, когда пришел на Oracle, задал вопрос - а почему бы не сложить простые справочники таким манером. В ответ на что получил просьбу назвать хотя бы одно осмысленное преимущество такой вот "кучи малы" (под неосмысленными я понимаю, например, экономию нескольких килобайт дискового пространства). Попробовал - и не смог. Так до сих пор и не могу, одни минусы.

SPQRНапример, унификация кода
Простите, это смешно, и если не ошибаюсь, уже упоминалось выше. В современных средствах разработки ни к какой дополнительной унификации кода это не приводит; если средство не позволяет редактировать одной формой разные таблицы - ему место в помойке, а не среди аргументов.

Под "одной формой" я имею в виду вовсе не обязательно один экземпляр класса, а нечто вроде "одного многократно используемого кода" - скажем, базовую форму "справочника" вместе с наследниками.

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

iscrafmнет, документы в данном случае - однотипные таблицы
Понятно. То есть чукча не читатель, главное встрять и что-нибудь ляпнуть.

iscrafm, то о чем речь в теме идет.
Попробуйте что ли прочитать тему. Хотя бы первое письмо, если уж на большее сил не хватает.