Добрый день, сообщество!

Хотелось бы разъяснить следующий вопрос, из за которого я со своим руководителем сцепился не на жизнь, а на смерть!

Рассмотрим, стандартную ситуацию: справочник заявок и атомарный справочник статусов заявок(открыта, закрыта, в процессе, это к примеру), в них связь один-ко-многим. Из справочник статусов формируется(select id value, name display from status) list of values(GUI элемент selectlist), из которого я и выбираю значение, а в таблицу заявок вставляется его код.
И таких пар в схеме может быть много, с использованием атомарных справочников.
Это обычный академический вариант, предложенный мной.

Руководитель предлагает:
Все эти справочники "согнать" в один общий справочник(аттрибуты: имя справочника, значение(аббревиатура), описание(то что пользователь будет видеть в приложении)), в котором будет поле "имя справочника", и по фильтру на котором я и получю нужный list of values. То есть никакой физической связи со справочником заявок не будет, а вся логика будет перенесена на уровень приложения, где я буду отслеживать из какого справочника мне нужен именно в этой таблице взять значение. Ладно я выбери из списка в приложении именно тот справочник и выберу в нем значение, и что дальше? что я вставлю в status таблицы заявок, код из общей таблицы справочников? А если какой нибудь справочник надо поменять, и не изменить значение, а добавить, то все записи сдвинутся, и коды поменяются(рассматриваю вариант с полным пересозданием) и тогда вообще будет охинея. А если вставлять не код, а как предлагает руководитель "значение", и типа это "значение" должно быть уникально во всех справочниках, но может же быть ситуация, что в разных справочниках может быть одно и тоже буквенное сочетание, но разное по описанию. То есть вставив это "значение", я не смогу произвести обратную трансформацию в display name статуса, так как мне возратится не одна запись а несколько из глобального справочника. Что бы обойти это, то нужно еще накладывать большую логику на приложение, что бы мне искать в глоб справочнике значение по определенному справочнику в зависимости от текущего состояния приложения. Еще выход - что бы сослаться уникально, то нужно использовать связку имя "справочника-значение" и хранить ее в id_status таблицы заявки. Соответственно здесь получается никакой физ. связи между мастер таблицей и атомарным справочником, и если поменяется что то в глобальной таблице это не приведет в изменении в ней. Надо жестко все контролировать на уровне приложения.

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

Вообщем такая, казалось бы, простая ситуация завела в "тупик"!

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

Спасибо за ответы

qwwq...поменять рукомахателя

Это не имеет отношения в сабжу! интересует практика...

Dimitry Sibiryakov,
Потому что это не есть уникальное определение определенного дискрипшена в глобальном справочнике, если брать все таки в учет что жизнь не статика, а что то может добавится, что приведет к сдвигу в этом глобальном справочнике.

Кот Матроскин,

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

Используется case-средство Oracle data modeler, дак вот за эти справочники отвечают так называемые домены, но при генерации они выражаются как в check constrans, что не совсем удобно, произведя некоторые манипуляции с импортов в бд метаданных проекта, вытаскиваю эти домены в одну таблицу - глобальный справочник. То есть каждый раз мне нужно его пересоздавать заново, так проще. и соответственно сиквенсы все собьются и ссылки будут уже на другое значения описания! А если как говорите вы, то это мне нужно делать дополнительную манипуляцию по вычислению разницы между двумя глобальными справочниками, новым и старым и добавлять только те значения, которые добавились, а если произошли изменения в значении описания....

Вообщем как то так, куда не кинь везде клин!

Infernal V. RavenDimitry SibiryakovА какой идиот не ссылается на первичный ключ?..
Да много кто. Oracle, например, в OeBS :)


Вот он про это постоянно и говорит, что сам оракл давно это использует.

Вижу еще одни + глобального листа - управления расположение в gui-селектлисте, например в справочнике городов, наверху всегда должны самые часто используемые - Питер, Москва и тд и тп. Но этот сиквенс можно вести и в отдельных справочниках, так что профит...

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

Вообщем все слилось в холивар, который я начал!

Так?

Значит и тот и другой вариант "хорош", и отталкиваемся лишь от архитектора, который несет ответственность за все в целом.

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

В моем случаи, получается, какой способ использовать что бы не было "бездумного следования какой-то одной идеологии"!?