Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Первая проблема с этим первичным ключом в том, что каждый элемент имеет смысл. Каждый элемент поддерживается человеком и может быть изменен или записан с ошибками. Два ключа ('Smith', 'Mary', '43889474') и ('SMITH', 'Mary', '43889474') Не являются одинаковыми и оба могут быть помещены в эту таблицу. Какая запись будет изменена, если магу выйдет замуж или изменит номер телефона?

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

Реальные накладки могут появиться, если эти столбцы используют многобайтовые наборы символов или не двоичные порядки сортировки. Размеры индексов ограничены 252 байтами. Для ключей обязательно создаются индексы. Такой ключ будет невозможен просто по причине слишком большого размера.

Создание атомарного ключа

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

Решение заключается в добавлении дополнительного столбца в таблицы для использования в качестве искусственного или суррогатного первичного ключа - уникальный, ограниченного размера столбец, желательно генерируемый системой, который заменяет (замещает) функцию теоретического первичного ключа. Firebird предоставляет объекты GENERATOR, которые могут быть использованы для создания требуемых уникальных серий чисел BIGINT для первичного ключа размером 8 байт или меньше.

Общую технику реализации автоинкрементного первичного ключа (при отсутствии ручной работы) см. в разд. "Генераторы" главы 9 ив главе 31.

! ! !

ВНИМАНИЕ! Атомарность ключа должна поддерживаться в приложениях сокрытием его от пользователя или хотя бы его свойством только для чтения.

. ! .

Итог - суррогатные ключи против естественных ключей

Разработчики баз данных обычно занимают четкую позицию "за" или "против" использования суррогатных ключей. Позиция автора по использованию атомарности очевидна. Несмотря на это, в интересах справедливости аргументы за и против представлены в табл. 14.1.

Таблица 14.1. Суррогатные (искусственные) ключи в сравнении с естественными

Особенность	За	Против
Атомарность	Суррогатные ключи не воспринимаются как данные и никогда не изменяются	Естественные ключи по своей сути нестабильны, потому что они являются предметом человеческих ошибок и внешних изменений
Удобство	Естественные ключи несут информацию, сокращающую необходимость выполнения соединений или дополнительных чтений для поиска данных в контексте. Естественные ключи более удобны при использовании в интерактивных инструментах запросов	Суррогатные ключи не несут никакой информации помимо их функции связи, требования соединений или подзапросов поиска связанных "осмысленных" данных
Размер ключа	Суррогатные ключи компактны	Естественные ключи имеют больший размер и часто усложняют составные ключи, которые усложняют запросы и схему
Навигация	Суррогатные ключи обеспечивают чистую, быструю навигацию по коду	Естественные ключи обычно не являются подходящими при навигации в стиле кода по причине порядка сортировки, денормализации и размера
Нормализация	Суррогатные ключи могут быть нормализованы в базе данных	Естественные ключи имеют тенденцию к усложнению, распространению денормализации данных внешних ключей