Мне не нравится одна вещь.

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

В случае с суррогатными идентификаторами и неидентифицирующими связями достаточно поменять внешний ключ cust_id в таблице order. Позиции заказа трогать не надо - они ссылаются на тот же order_id.

В случае же идентифицирующих отношений и миграции ключей нам потребуется не только изменение cust_id в order, но и каскадное изменение cust_id в order_items. Причем, заметьте, в обоих таблицах меняется часть первичного ключа, что само по себе нехорошо во многих случаях. И еще здесь можно усмотреть нарушение нормализации - зависимость между атрибутами. А именно, в таблице order_items поле cust_id однозначно определяется полем order_id. Все равно что поле X^2 рядом с полем X.

А довод о повышении производительности агрегирующих запросов, и что "очень легко получить данные о том, сколько штук чего-то там заказал за историю покупок ваш клиент" (отсутствие необходимости JOIN-ов) с одной стороны верны, но с другой стороны - не совсем. С теми же доводами поля любого справочника, по полям которого нужна агрегация, можно продублировать в главной таблице. Допускаю, что иногда это оправдано (денормализация для увеличения производительности), но как общий аргумент (что это хорошо и правильно всегда) - вряд ли.

AK-74UКак уже сказали до меня выше, миграция первичных ключей не может рассматриваться в качестве избыточности. Потому что это первичный ключ. Он един и неделим в своём качестве.

Я вовсе не пытаюсь уличить в безграмотности все учебники :-) Действительно, миграция ключей не является формальным нарушением нормальных форм, во всяком случае упоминавшихся 3NF и NFBK - там четко сказано о зависимостях неключевых атрибутов. Я лишь обратил внимание, что при миграции ключей может возникнуть ситуация "подправил здесь - не забудь подправить и там", что сходно с поведением денормализованных таблиц, и само по себе неприятно.

AK-74UКак я понимаю, дело в том, что если вы подразумеваете возможности перекидки заказа от одного клиента к другому, это уже по умолчанию означает что заказ не идентифицируется клиентом, а существует как не зависимая, в принципе, от клиента сущность, хотя и NULLS NOT ALLOWED :) То есть, собственно, никакой идентифицирующей связи изначально.

Здесь я не совсем согласен. IMHO, идентифицирующая связь между заказом и клиентом совсем не означает, что заказ нельзя перекинуть между клиентами. Перекинуть в наше время можно абсолютно все, даже области бывшего СССР между странами, хотя раньше за одну мысль об этом полагались крупные неприятности.

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

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

А как же суррогатные ключи? Здесь нужно помнить, что введение суррогатного ключа - это "механическая операция, которая никак не нарушает инфологической модели и целостности данных. С точки зрения инфологической модели эти две базы данных эквивалентны." (c) А. Тенцер. То есть введение суррогатного ключа, и обеспечение уникальности таким образом вовсе не снимает идентифицируемости связи. Просто рассуждения об уникальности и идентификации переносятся с первичного ключа на альтернативные, подобно тому, как при введении суррогатного ключа старый PRIMARY KEY заменяется на UNIQUE CONSTRAINT.

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