kasik атомарный справочник статусов заявок

Поясни, пожалуйста, что такое "атомарный справочник" ?
Справочник атомарных весов химических элементов таблицы Менделеева ?

Все эти справочники "согнать" в один общий справочник
(аттрибуты:
имя справочника,
значение(аббревиатура),
описание(то что пользователь будет видеть в приложении)
),

в котором будет поле "имя справочника", и по фильтру на котором я и получю нужный list of values.


Ну, что ж, так иногда делают, особенно это полезно, когда таких простейших справочников очень много. Типа 200.
Тогда это очень выгодно.


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


Физическая связь может и присутствовать, другое дело, ты не сможешь средствами СУБД (констрейнтов) контролировать, что
в нужную таблицу попали значения именно из нужного справочника. Это не страшно, это можно контролировать логикой приложения, реализованной в триггерах, хранимых процедурах или каком-то ещё коде. Не обязательно это контролировать в самой БД.


Ладно я выбери из списка в приложении именно тот справочник и выберу в нем значение, и что дальше? что я вставлю в status таблицы заявок, код из общей таблицы справочников? А если какой нибудь справочник надо поменять, и не изменить значение, а добавить, то все записи сдвинутся, и коды поменяются(рассматриваю вариант с полным пересозданием)


Это с какого перепугу ? PK никогда не меняются.


и тогда вообще будет охинея. А если вставлять не код, а как предлагает руководитель "значение", и типа это "значение" должно быть уникально во всех справочниках, но может же быть ситуация, что в разных справочниках может быть одно и тоже буквенное сочетание, но разное по описанию. То есть вставив это "значение", я не смогу произвести обратную трансформацию в display name статуса, так как мне возратится не одна запись а несколько из глобального справочника. Что бы обойти это, то нужно еще накладывать большую логику на приложение, что бы мне искать в глоб справочнике значение по определенному справочнику в зависимости от текущего состояния приложения. Еще выход - что бы сослаться уникально, то нужно использовать связку имя "справочника-значение" и хранить ее в id_status таблицы заявки. Соответственно здесь получается никакой физ. связи между мастер таблицей и атомарным справочником, и если поменяется что то в глобальной таблице это не приведет в изменении в ней.


Всё это я нифига не понял.

Надо жестко все контролировать на уровне приложения.


Да, надо. Ничего страшного. И главное -- её надо контролировать и так, и так. Т.е. по-любому эта логика должна быть,
а в БД или на среднем слое должна быть ещё одна такая же. Увы.



Но это как то получается все оч толсто!!!

Жызнь ваапще сложная штука...


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

Тут руководитель не совсем прав.
FK, если их можно сделать, очень хорошая штука. Но как правило это -- 20 подстраховка в самом-самом нижнем уровне.
Когда всё остальное уже отработало и 3 раза всё перепроверило. Но это не значит, что их не нужно делать, НУЖНО.
И особенно они хороши, когда данные правят программисты руками -- там уже 3 перепроверок нет, и остаются одни констрейнты.




Итого.
ЕДиний общий справочник вместо 200 одинаковых типа "ключ-значение" -- это благо.
FK при этом НАДО создавать. ПОтому что любые декларативные констрейнты в БД -- тоже благо (если очень не мешают производительности).
FK при этом теряет немного свою мощность, так как не может проверить, что дочерняя сущность ссылкается на значение справочника именно нужного типа. Поэтому, если можно, лучше проверять это дополнительно, в коде процедур, триггерами или на среднем слое в сервере приложений.

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

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

gender ('M', 'F')
marital_status( 'SNGL', 'MR', 'WD', 'DV' )


и так далее.

Но ежели вы уж используете числовые идентификаторы, то какого ж фига вы их каждый раз перенумеровываете ?
Не, если каждый раз БД с нуля генерируется, то можно, но если нет -- менять их нельзя.

Dimitry SibiryakovSERG1257Приведите нормальный реальный измеримый выигрыш. Хоть один. Замена
нормальных физических таблиц логическими (размазанными по приложению запросами или
вьюхами) ну никак не тянет на выигрыш. Зачем делать за СУБД ее работу?
Например затем, что в этом случае добавление нового справочника не требует написания новых
запросов и/или использования динамического SQL. Не требует создания новых форм его
редактирования/наполнения/выбора. Не требует права на CREATE TABLE и потому может
осуществляться даже ограниченным пользователем.



Ещё "очень выгодно" такое, если надо находу добавить новый справочник.