Суррогат по сравнению с естественными/бизнес-[закрытыми] ключами

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

Суррогатные ключи могут быть полезными, когда бизнес-информация может измениться или быть идентичной. Названия компании не должны быть уникальными по всей стране, в конце концов. Предположим, что Вы имеете дело с двумя компаниями под названием Smith Electronics, один в Канзасе и один в Мичигане. Можно отличить их адресом, но это изменится. Даже состояние может измениться; что, если Smith Electronics Канзас-Сити, Канзас продвигается по реке в Канзас-Сити, Миссури? Нет никакого очевидного способа сохранить эти компании отличными с естественной ключевой информацией, таким образом, суррогатный ключ очень полезен.

Думают о суррогатном ключе как число ISBN. Обычно, Вы определяете книгу заголовком и автором. Однако у меня есть две книги, названные "Перл-Харбор" H. P. Willmott, и они - определенно различные книги, не только различные выпуски. В случае как этот я мог обратиться к взглядам книг, или ранее по сравнению с позже, но это точно также, у меня есть ISBN для возвращений.

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

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

Бизнес-логика / естественные ключи может измениться, но физический ключ таблицы никогда не должен изменяться.

На datawarehouse сценарии я верю, лучше для следования за путем суррогатного ключа. Две причины:

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

Суррогатные ключи довольно удобны, если Вы планируете использовать инструмент ORM для обрабатывания/генерирования классов данных. В то время как можно использовать составные ключи с некоторыми более усовершенствованными картопостроителями (чтение: будьте в спящем режиме), это добавляет некоторую сложность к Вашему коду.

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

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

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

Alway используют ключ, который не имеет никакого бизнес-значения. Это - просто хорошая практика.

РЕДАКТИРОВАНИЕ: Я пытался найти ссылку на него онлайн, но я не мог. Однако в 'Шаблоны Предприятия Archtecture' [Fowler] это имеет хорошее объяснение того, почему Вы ничего не должны использовать кроме ключа без значения кроме того, чтобы быть ключом. Это сводится к тому, что это должно иметь одно задание и одно задание только.

Суррогатный ключ никогда не будет иметь причины измениться. Я не могу сказать то же о естественных ключах. Фамилии, электронные письма, ISBN nubmers - они все могут измениться однажды.

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

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

Думают Компании: Вы - счастливая компания Merkin, поддерживающая деловые отношения с другими компаниями в Merkia. Вы достаточно умны для не использования названия компании в качестве первичного ключа, таким образом, Вы используете уникальный идентификатор компании правительства Merkia в целом 10 алфавитно-цифровых символов. Тогда Merkia изменяет идентификаторы компании, потому что они думали, что это будет хорошая идея. Это в порядке, Вы используете каскадную функцию обновлений механизма своего дб, для разнообразия который не должен вовлекать Вас во-первых. Позже, Ваш бизнес расширяется, и теперь Вы работаете с компанией в Freedonia. Идентификатор компании Freedonian является до 16 символов. Необходимо увеличить идентификационный первичный ключ компании (также поля внешнего ключа в Заказах, Проблемах, MoneyTransfers и т.д.), добавив поле Country в первичном ключе (также во внешних ключах). Ай! Гражданская война в Freedonia, это разделяется в трех странах. Название страны Вашего партнера должно быть изменено на нового; каскадные обновления спасения. BTW, каков Ваш первичный ключ? (Страна, CompanyID) или (CompanyID, Страна)? Последний помогает соединениям, первый избегает другого индекса (или возможно многие, должны Вы хотеть свои Заказы, сгруппированные страной также).

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

Кажется, что никто ничего еще не сказал в поддержку несуррогата (я смущаюсь говорить "естественный"), ключи. Таким образом, здесь идет...

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

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

против:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

, Если кто-либо серьезно не думает, следующее является хорошей идеей?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

, "Но" кто-то скажет, "что происходит, когда код для MYPROJECT или ДОПУСТИМЫЙ или HR изменяется?" К которому мой ответ был бы: "почему был бы Вы потребность для изменения его?" Это не "естественные" ключи в том смысле, что некоторое внешнее тело собирается издать законы, это впредь 'ДОПУСТИМОЕ' должно быть повторно кодировано как 'ХОРОШЕЕ'. Только небольшой процент "естественных" ключей действительно попадает в ту категорию - SSN и почтовый индекс, являющийся обычными примерами. Я определенно использовал бы бессмысленный числовой ключ для таблиц как Человек, Адрес - но не для [1 113] все , который по некоторым причинам большинство людей здесь, кажется, защищает.