Возьмите пример таблицы с двумя ключами-кандидатами: один простой (с одним столбцом) и один составной (с несколькими столбцами). Ваш вопрос в этом контексте выглядит следующим образом: «Какой недостаток я могу испытать, если я выберу один ключ как« первичный »и выберу составной ключ?»
Во-первых, подумайте, нужно ли вам вообще продвигать ключ: «само существование PRIMARY KEY в SQL кажется исторической случайностью какого-то рода. По мнению автора Криса Дейта, самые ранние воплощения SQL не делали этого». У него не было каких-либо ключевых ограничений, и PRIMARY KEY был добавлен только позже в стандарты SQL. Разработчики стандарта, очевидно, взяли термин от EFCodd, который изобрел его, хотя первоначальное представление Кодда к тому времени было заброшено! (Кодд первоначально предлагал что внешние ключи должны ссылаться только на один ключ - первичный ключ - но эта идея была забыта и проигнорирована, потому что она была широко признана как бессмысленное ограничение). " [источник: Блог Дэвида Портаса: долой первичные ключи?
Во-вторых, какие критерии вы бы применили, чтобы выбрать, какой ключ в таблице должен быть «основным»?
В SQL выбор ключа PRIMARY KEY является произвольным и зависит от продукта. В ACE / Jet (он же MS Access) двумя основными и часто конкурирующими факторами является то, хотите ли вы использовать PRIMARY KEY для поддержки кластеризации на диске или хотите, чтобы столбцы, содержащие ключ, отображались жирным шрифтом на изображении «Отношения» в пользовательский интерфейс MS Access; Я в меньшинстве, думая, что стратегия индекса превосходит красивую картинку :) В SQL Server вы можете указать кластерный индекс независимо от PRIMARY KEY, и, похоже, преимущества для конкретного продукта не предоставляются. Единственное оставшееся преимущество, по-видимому, заключается в том, что вы можете опустить столбцы PRIMARY KEY при создании внешнего ключа в SQL DDL, что является поведением стандарта SQL-92 и в любом случае не кажется мне таким уж большим (возможно, другим одна из вещей, которые они добавили в стандарт, потому что эта функция уже широко распространена в продуктах SQL?) Итак, дело не в поиске недостатков, а в том, чтобы посмотреть, какое преимущество , если любой, ваш продукт SQL дает PRIMARY KEY. Другими словами, единственный недостаток при выборе неправильного ключа - то, что вы можете упустить данное преимущество.
В-третьих, вы скорее намекаете на использование искусственного / синтетического / суррогатного ключа для реализации в вашей физической модели ключа-кандидата из вашей логической модели, потому что вы обеспокоены тем, что если вы будете использовать естественный ключ в внешних ключах, то это приведет к снижению производительности стол включается? Это совершенно другой вопрос, и он во многом зависит от вашей «религиозной» позиции по вопросу о естественных ключах в SQL.