Bogdanov AndreyСначала искуственно создаем проблему, запихивая справочники в одну таблицу. А потом пытаемся ее решать. Я так понял, что ваша реплика была в защиту дизайна при котором все справочники запихиваются в одну таблицу.Я ничего не защищал. Это Вы сделали утверждение, а я лишь привел пример, когда оно не соответствует истинности.

Bogdanov AndreyЧестно скажу, что предлагаемое решение мне категорически не нравится. Мне в общем-то достаточно и эстетических соображений. Но могу привести и другие: например, объем таблицы с данными разбухает вдвое. Не особенно удобно предлагаемое решеие и для разработки приложений, так как заставляет где-то иметь списки констант, представляющих тот или иной справочник.Мне оно тоже не особенно нравится, но были прецеденты, когда это оказывалось самым простым решением. Насчет "вдвое", это кхм... несколько завышенная оценка. А все константы явно описаны в таблице DictionaryType, и нет нужды ни в каком дополнительном описании где-бы то ни было еще.

Bogdanov Andrey ChA А теперь представьте, что документ может иметь взаимоисключительное отношение либо к сотруднику, либо к отделу, либо к партнеру.Это означает, что документ имеет отношение к некоторой сущности, которая называется скажем "субъект". А уж сотрудник, отдел или партнер - подтипы данной сущности. Итого мы имеем один справочник под названием "Субъекты" и три дочерних справочника. Но при этом никаких DictType в таблице данных у нас не будет.Браво. Я не шучу, и полностью с Вами согласен по данному конкретному случаю. Более того, равным же образом проходило подобное же обсуждение в аналогичной ситуации. Собственно, все pro и contra там уже упомянуты. Но при таком решении там тоже возникает неувязочка. Теоретически никто не мешает в разные таблицы упомянутых подсправочников точно также сунуть объекты с одним и тем же идентификатором. Как там насчет избыточности и дополнительных ограничений ? :)
По моему, и, если не ошибаюсь, уважаемого ModelR, подобные решения хороши(и это упомянуто по ссылке) в случае хорошо описанной и вполне статичной модели. К сожалению, в России(о других странах сказать ничего не могу) это не не очень актуально, так как на это либо нет денег, либо времени, либо специалистов, как со стороны заказчика, так и клиента. Не считая аппетитов, которые, как правило, сильно возрастают в процессе реализации. IMHO, это некоторые из причин, которые привели к популярности в России модели EAV, но это уже другая тема.
В принципе, изначальная тема для обсуждения, на мой взгляд, исчерпана. Есть проблема - есть решение, все остальные рассуждения о правильности и тому подобном, относятся к категории благих пожеланий.

P.S. Как мне кажется, любой западный специалист по финансовым системам свихнется на методиках нашего бухгалтерского учета. :)

Прошу прощения, ссылка должна была выглядеть так .