blest,

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

Вообще соотношений типа (1:1) OR (1:1) лучше избегать.

Но дело ваше.

Попробуйте сделать так (псевдокод, проверять некогда)

Теперь вы никак не сможете вставить запись из contractors с одним же и тем же ID + TYPE_C сразу в разные таблицы, за этим проследит поле TYPE_C, точнее constraints в подчиненных таблицах.

Минус в том, что constraints можно отключать, но и FK тоже можно удалять. :)

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

уТКаэтот вопрос вроде как плодотворно обсудили здесь

В этом обсуждении как-то незамеченным остался философский вопрос: кого считать одним и тем же контрагентом?

Если для фискальных целей очевидно, что юридическое лицо "ООО Василек" и физическое лицо "Вася" это никак не связанные вещи (ну есть некоторые нюансы по тому, кто и как будет отвечать по долгам Васи), то для фирмы у которой этот Вася покупал 10 лет электроинструмент, это далеко не так.
Также возникают проблемы с отчетностью за разное время и т.п.

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

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

Соответственно, если мы ведем две отдельные таблицы для контрагентов юриков и физиков получается, что вполне ДОПУСТИМО существование в обоих таблицах ID одного и того же контрагента (разруливать кем он является сейчас, и кем и когда являлся ранее, можно через промежуточную темпоральную таблицу)!

Более того, никто не мешает тому же Василию благополучно разориться как ООО и стать снова Василием, а потом опять стать юриком, но уже "ЗАО "Эх ухнем"".

Т.е. получается, что в обоих таблицах реквизитов возникнет необходимость иметь по несколько записей для контрагента с одинаковым ID (т.е. АК надо стоить по ID контрагента и ID из промежуточной темпоральной таблице)!

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

Мы опять вернемся к вопросу о том, куда добавлять эти реквизиты?
В уже существующие таблицы, где они явно будут "путаться под ногами" для отечественных контрагентов, или городить для них свои таблицы?

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

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