Ключ или отмычка - Почему выбирают суррогатные ключи
Связи между таблицами на основе суррогатных ключей
Усложнение базы данных

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

Усложнение структуры базы данных вполне закономерно. Предположим, что сущность имеет интеллектуальный ключ, но помимо него был введён ещё и суррогатный ключ. Ввод дополнительного атрибута в каждую таблицу сам по себе усложняет структуру базы данных. Но, чтобы не нарушать 3НФ (о чём говорилось ранее) и ограничения предметной области необходимо поддерживать уникальность и интеллектуального, и суррогатного ключей одновременно. Соответственно, количество структур, с помощью которых поддерживается уникальность (как правило, уникальных индексов), увеличивается. И так по каждому отношению, обладающему интеллектуальным ключом.

Усложнение логики базы данных не столь очевидно и на этом вопросе стоит остановиться более подробно. Интеллектуальный ключ, являясь внешним ключом, содержит полезную информацию, и эта информация может быть использована в рамках ссылочного отношения, содержащего данный внешний ключ. Например, есть общероссийский классификатор товаров, где каждый вид товаров или товарная группа (классификатор имеет иерархическое строение) обладают уникальным номером. Предположим, что у нас есть отношение, которое фиксирует только продуктовые товары, ссылаясь при этом на общероссийский классификатор. При использовании интеллектуального внешнего ключа можно на поле внешнего ключа наложить дополнительное ограничение диапазона значений. Теперь проектировщики могут быть спокойны за то, что в отношение продуктовых товаров не попадёт иной товар, поскольку код другого товара будет вне диапазона значений, отведённого для продуктовых товаров. То есть, при попытке ввода товара, не относящегося к продуктовой группе, произойдёт нарушение ограничения наложенного на внешний ключ. Можно ли сделать подобное ограничение на суррогатных ключах? Нет, без введения дополнительных механизмов, нельзя, и вот почему. При создании отношения «Продуктовые товары» ещё не известно, какие значения будут присвоены суррогатному ключу у тех или иных категорий товаров, и, тем более, неизвестно будут ли продуктовые товары представлены диапазоном значений или некоторой произвольной последовательностью номеров, так, что между номерами продуктовых товаров окажутся номера совсем иных товаров. Как следствие, в случае использования суррогатных ключей придётся реализовывать какие-то сложные логические конструкции, которые бы поддерживали достоверность данных в отношении «Продуктовые товары».

В качестве другого примера использования значений внешнего ключа можно рассмотреть машиностроительную базу данных. Здесь довольно много информации представлено в виде справочников, в том числе, есть и справочники различных коэффициентов. Теперь представим, что в базе данных хранится некоторая сборочная единица, при расчёте которой использован некоторый коэффициент, описанный в одной из справочных таблиц.

TABLE COEFFICIENTS (
    COEF          DECIMAL(8.2) NOT NULL PRIMARY KEY,
    DESCRIPTION   VARCHAR(255) NOT NULL,
    ...);
TABLE NODES (
    PART_NO       CHAR(15) NOT NULL PRIMARY KEY,
    COEF          DECIMAL(8.2) NOT NULL REFERENCES COEFFICIENTS,
    FIELD_A       INTEGER NOT NULL,
    FIELD_B       DECIMAL(9.5) NOT NULL,
    ...
CHECK   ((FIELD_A * COEF) < FIELD_B),
    ...);

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