|
Все эти справочники "согнать" в один общий справочник
(аттрибуты:
имя справочника,
значение(аббревиатура),
описание(то что пользователь будет видеть в приложении)
),
в котором будет поле "имя справочника", и по фильтру на котором я и получю нужный list of values.
Ну, что ж, так иногда делают, особенно это полезно, когда таких простейших справочников очень много. Типа 200.
Тогда это очень выгодно.
То есть никакой физической связи со справочником заявок не будет, а вся логика будет перенесена на уровень приложения, где я буду отслеживать из какого справочника мне нужен именно в этой таблице взять значение.
Физическая связь может и присутствовать, другое дело, ты не сможешь средствами СУБД (констрейнтов) контролировать, что
в нужную таблицу попали значения именно из нужного справочника. Это не страшно, это можно контролировать логикой приложения, реализованной в триггерах, хранимых процедурах или каком-то ещё коде. Не обязательно это контролировать в самой БД.
Ладно я выбери из списка в приложении именно тот справочник и выберу в нем значение, и что дальше? что я вставлю в status таблицы заявок, код из общей таблицы справочников? А если какой нибудь справочник надо поменять, и не изменить значение, а добавить, то все записи сдвинутся, и коды поменяются(рассматриваю вариант с полным пересозданием)
Это с какого перепугу ? PK никогда не меняются.
и тогда вообще будет охинея. А если вставлять не код, а как предлагает руководитель "значение", и типа это "значение" должно быть уникально во всех справочниках, но может же быть ситуация, что в разных справочниках может быть одно и тоже буквенное сочетание, но разное по описанию. То есть вставив это "значение", я не смогу произвести обратную трансформацию в display name статуса, так как мне возратится не одна запись а несколько из глобального справочника. Что бы обойти это, то нужно еще накладывать большую логику на приложение, что бы мне искать в глоб справочнике значение по определенному справочнику в зависимости от текущего состояния приложения. Еще выход - что бы сослаться уникально, то нужно использовать связку имя "справочника-значение" и хранить ее в id_status таблицы заявки. Соответственно здесь получается никакой физ. связи между мастер таблицей и атомарным справочником, и если поменяется что то в глобальной таблице это не приведет в изменении в ней.
Всё это я нифига не понял.
Надо жестко все контролировать на уровне приложения.
Да, надо. Ничего страшного. И главное -- её надо контролировать и так, и так. Т.е. по-любому эта логика должна быть,
а в БД или на среднем слое должна быть ещё одна такая же. Увы.
Но это как то получается все оч толсто!!!
Жызнь ваапще сложная штука...
Но руководитель настаивает что это бэст практишь и вообще все отходят от форин ключей, и хранят сами значения, а не ссылки на них ввиде идентификатора, как по науке.
Тут руководитель не совсем прав.
FK, если их можно сделать, очень хорошая штука. Но как правило это -- 20 подстраховка в самом-самом нижнем уровне.
Когда всё остальное уже отработало и 3 раза всё перепроверило. Но это не значит, что их не нужно делать, НУЖНО.
И особенно они хороши, когда данные правят программисты руками -- там уже 3 перепроверок нет, и остаются одни констрейнты.
Итого.
ЕДиний общий справочник вместо 200 одинаковых типа "ключ-значение" -- это благо.
FK при этом НАДО создавать. ПОтому что любые декларативные констрейнты в БД -- тоже благо (если очень не мешают производительности).
FK при этом теряет немного свою мощность, так как не может проверить, что дочерняя сущность ссылкается на значение справочника именно нужного типа. Поэтому, если можно, лучше проверять это дополнительно, в коде процедур, триггерами или на среднем слое в сервере приложений.
|
