Эммм. А можно поинтересоваться - юрлица/физлица и т.п. у вас вне договора не существуют? И если на одно лицо несколько договоров - данные будут создаваться несколько раз?

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

ИМХО, EAV сюда пихать не стоит - чистейший оверкилл.

Да об этом уже выше писалось - надо как-то гарантировать, чтобы ID разнотипных сущностей не пересекались. Если не использовать непересекающиеся диапазоны, то можно ввести поле - тип сущности - в общую таблицу и проверку в CHECK(через функцию) | TRIGGER: чтобы сущность с вносимым ID существовала (если она существует) только в таблице, соответствующей конкретному типу. Или использовать GUID :)

explaSinix,

займитесь лучше проектированием транзакций. Правильные транзакции всегда оставляют за собой правильные данные. FK и PK нужно рассматривать как механизм защиты данных от разрушения в результате параллельного выполнения конкурирующих транзакций (одна удаляет PK, другая в то же время добавляет FK). Строить на FK правила проверки правильности данных пустая трата времени (данные легко проверить простыми SQL запросами).

Ваши FK лишь не позволят работать неправильным транзакциям, которых не должно быть в системе.

та-та ?)

Умиляют категоричесие суждения про лёгкость поверки запросами и про правильные транзакции.
Вы случаем не путаете транзакции с запросами? Подучите матчасть, плиииз.

Как нам помогут транзакции, когда в одной транзакции создаётся общая сущность с ID=1 и для неё создаются details в таблицах юрлиц и физлиц?

По порядку.

2 vbgd:
1) ранняя оптимизация зло.
2) изменение структуры данных ради оптимизации зло

Единственное, чего можно добиться денормализацией - повышение производительности select запросов. (опечатка оператора была). Это должно отражаться в накладной? Если нет - то какой адрес настоящий? Если да, то потребуется писать триггер на обновление у таблицы "заказчики" и обновлять в нём все "кэшированные" адреса. Если у вас в накладных хранятся данные и из другой таблицы - вам придётся писать триггеры и на эти таблицы. В результате одна операция правки адреса утопит в блокировках (если это блокировочник) половину БД.

Да, здесь выигрыш от денормализации будет сопоставим с построением составного индекса по ключу заказчика/адресу. Адрес может быть просто включённым полем. Всё просто :)

2 expla:
Для начала давайте договоримся:
Запрос - обращение пользователя к СУБД, содержащее в себе несколько выражений DML/DDL
Транзакция - средство обеспечения ACID для пользовательского запроса. Вы не можете никак вмешаться в алгоритм работы транзакции. Максимум, что вам удастся - порулить блокировками - опять-таки через ващ запрос.

Крактко: Транзакция не может быть некорректной, некорректным может быть только запрос.

Как я буду проверять корректность запроса - заранее не скажу. Может, триггеры. Может, проверки на столбце через функцию. Смотреть надо. Но то что дело реализуемое - эт точно.

2 mcureenab:

Про неправильность транзакций - выше. Вам что, всем по одному недоучебнику что-то рассказывали ?:) // сорри, не удержался.

Про "нетривиальность" связи. Скажите, а ОО(Р)СУБД как-то иначе реализуют такие проверки? Уличная магия, да? :)

Про непригодность ограничений: не, вы точно какой-то не тот учебник курили. Кто вам сказал, что ER-диагармма - наше всё? У ER есть свои недостатки и преимущества, но вот описывать в ней концептуальную модель - брр :) Скажите, а как вы отслеживаете корректность данных? Своя логика в каждом запросе? Что будет, если всего в одном запросе будет допущена ошибка в проверке ограничений?

P.S. Я ничего не пытаюсь использовать и реализовывать. Подняли тему, я пришёл и сказал своё мнение. Закрыли тему? :)