VladShПрименительно к физическим-юридическим лицам и т.д.
лучший вариант - хранить данные не в двух разных таблицах, а в одной.
Меня всегда умиляли слова "лучше так" при абсолютно неизвестной постановке задачи (то есть - как именно будет использоваться это "так").

VladShНапример CUSTOMER.
Если CUSTOMER - то действительно например. Но подброшу другой например, из моей практики: хранятся данные о самой фирме и ее филиалах (сотрудники и оргструктура), контрагентах (те самые customer), банках (которые само собой юрики и которые могут быть контрагентами) ключевых сотрудниках контрагентов-юриков и банков (грубо говоря, контакты), расчетных счетах, которые физик или юрик может иметь в банке.

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

KezyaСделал одно поле - внешний ключ и поле-признак, значение в котором и будет означать из какой сущности взят экземпляр.
Присоединюсь к предыдущим ораторам. Это решение во-первых наиболее неудобно в использовании, а во-вторых, наиболее ненадежно, чревато проблемами в сопровождении (разрешите не расшифровывать почему, если угодно - просто точка зрения).

Нормальные решения уже были названы - это либо "сквозная" таблица, объединяющая две сущности, либо то, что в Oracle Designer-е называется "дугой" - два поля, два foreign key и check constraint вида (a is null and b is not null or a is not null and b is null).

KezyaПервичный ключ для таблицы состоял из трех внешних ключей, теперь же добавляется четвертый,
"А зачем нам кузнец?" (c)

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

ASCRUS(если конечно Оракл позволяет нормально делать UNIQUE на NULL-поля).
Позволяет. Даже позволяет создать foreign key, ссылающийся на такой unique constraint.

rtwertwertwertwertwertwertwet
а вдруг станет? что будете делать - харакири?
Да бог с ним. Возражение гораздо проще - у меня упомянута, например, таблица банков, которая ссылается на юриков (банк физиком быть не может). Еще там упомянуты сотрудники, которые вряд ли могут быть кем-то кроме физиков. Итого, если валить физиков с юриками в одну таблицу - начинаются пляски с целостностью. Правда, уже было задекларировано "зло", на что трудно возразить :)