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

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

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

таблица <- колонки таблицы
таблица <- отчет
отчет <- колонки отчета
колонки таблицы <- колонки отчета

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

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

MaryCatНасколько помнится, нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Т.е. строку в таблице можно было идентифицировать единственным способом.
Вне зависимости от того, требует или нет, требование совершенно идиотское. Скажем, что делать с таблицей Люди (имя, номер_паспорта, инн)? Пилить на две?

ChAНе понял, какое отношение имеет составной ключ к денормализации. Где и какая нормальная форма нарушается ?
Зависит от. Скажем, в приведенном мной примере подразумевается нарушение второй.

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


Что касается table#, с ним все понятно - самый обычный автоинкрементный ключ. Интерес представляют колонки report# и table_column#. У нас есть выбор:

1. Сделать их уникальными (то есть потенциальными ключами), опять же обычный автоинкремент.
2. Сделать их уникальными в пределах #table, но не гарантируя уникальность вообще.

Полагаю, очевидно, что первое решение "гарантированно не хуже" второго. Гарантированно - в том плане, что это "второе плюс дополнительное требование", а следовательно, любая аномалия, допускаемая первым, допускается и во втором итп. Короче говоря, множество недостатков первого подхода содержится во множестве недостатков второго подхода. Мало того, легко назвать, чем первых подход лучше, то есть включение строгое, множества не равны. Однако! Однако, второй подход строго соблюдает нормальные формы, в то время как первый - нарушает.

По этой причине мне кажется правильным рассматривать фактическую ситуацию, не переоценивая формальные критерии соответствия.

mcureenabПилить. На "Паспорта" и "Свидетельства о постановке на учёт в налоговой".
И зачем? Чтобы скучно не было?

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