Вы выбираете подход, когда Организации (OrgTable) и Пользователи (UserTable) у Вас суть две разные сущности. Я бы предложил подумать над вариантом объединить их в одну сущность, скажем, Клиент. Тут проблемы с целостностью уже не возникнет, ибо формально таблица одна. Реально же их будет три - Client, ClientOrganizationExtended и ClientPersonExtended. В основной будут только базовые совместимые характеристики, в Extended - дополнительные и уникальные для типа клиента характеристики. Да, контроль целостности типа "вилка" останется. Но критичность нарушения целостности резко снизится, потому можно будет использовать методы контроля целостности, допускающие нарушение (удаление при CHECK CONSTRAINT, например). А можно вообще вместо двух Extended-таблиц пойти на создание одной EAV-таблицы. Там, правда, свои заморочки.
В общем, куда не плюнь, везде свои минусы... да, есть и ещё варианты, и тоже с минусами - фантазия-то у нас безгранична.

ProBiotekЧто означает "удаление при CHECK CONSTRAINT" ? Каким образом это реализуется ?
То, что тебя смутило в соседней теме " Как сделать такое ограничение ? ". Ни больше ни меньше...

Владислав КолосовКак вариант - отказаться от нормализации и собрать в общий "хвост" обе таблицы OrgTable и UseTable. Тогда появятся незаполненные поля.Пустые поля - не так страшно, как избыточные индексы. С хреновой тучей NULL-ов.

Модератор: Тема перенесена из форума "Microsoft SQL Server".