Всегда используйте ключ, не имеющий коммерческого значения. Это просто хорошая практика.

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

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

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

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

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

На мой взгляд, лучше использовать суррогатный ключ, так как вероятность его изменения равна нулю. Почти все, что я могу придумать, что вы можете использовать в качестве естественного ключа, может измениться (отказ от ответственности: не всегда верно, но обычно).

Примером может служить БД автомобилей - на первый взгляд может показаться, что в качестве ключа можно использовать номерной знак. Но их можно изменить, так что это плохая идея. На самом деле вам не захочется узнавать об этом после выпуска приложения, когда кто-то приходит к вам, желая узнать, почему они не могут поменять свой номерной знак на свой новый блестящий персонализированный.

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

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

Бизнес-логика / естественные ключи могут изменяться, но физический ключ таблицы НИКОГДА не должен меняться.

Я считаю, что в сценарии хранилища данных лучше следовать пути суррогатного ключа. Две причины:

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

Случай 1. Ваша таблица является таблицей поиска с менее чем 50 записями (50 типов).

В этом случае используйте ключи с именами вручную в соответствии со значением каждой записи.

Например:

Table: JOB with 50 records
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Случай 2. Ваша таблица представляет собой таблицу с тысячами записей.

Используйте суррогатные ключи / ключи автоинкремента.

Например:

Table: ASSIGNMENT with 1000000 records
joined with
Table: PEOPLE with 100000 records

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

В первом случае:

• Вы можете выбрать всех программистов в таблице PEOPLE без использования соединения с таблицей JOB, но только с помощью: SELECT * FROM PEOPLE WHERE JOBCODE = 'PRG'

Во втором случае:

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

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

Думайте о суррогатном ключе как о номере ISBN. Обычно вы определяете книгу по названию и автору. Однако у меня есть две книги под названием «Перл-Харбор» Х. П. Уиллмотта, и это определенно разные книги, а не просто разные издания. В подобном случае я мог бы сослаться на внешний вид книг или более ранний по сравнению с более поздним, но с тем же успехом у меня есть ISBN, на который можно опираться.

Напоминаем, что не рекомендуется размещать кластеризованные индексы на случайных суррогатных ключах, то есть идентификаторах GUID, которые читают XY8D7-DFD8S, поскольку SQL Server не имеет возможности физически сортировать эти данные. Вместо этого вам следует разместить уникальные индексы для этих данных, хотя может быть также полезно просто запустить профилировщик SQL для основных операций с таблицами, а затем поместить эти данные в помощник по настройке ядра СУБД.

См. Ветку @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

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

В случае базы данных на определенный момент времени лучше всего использовать комбинацию суррогатных и естественных ключей. например вам необходимо отслеживать информацию о членах клуба. Некоторые атрибуты члена никогда не меняются. например, Дата рождения, но имя может измениться. Итак, создайте таблицу Member с суррогатным ключом member_id и получите столбец для DOB. Создайте еще одну таблицу с именем person name и добавьте столбцы для member_id, member_fname, member_lname, date_updated. В этой таблице естественным ключом будет member_id + date_updated.

Лошадь для курсов. Чтобы заявить о моей предвзятости; Я в первую очередь разработчик, поэтому я в основном озабочен тем, чтобы предоставить пользователям работающее приложение.

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

Я работал с системами только с суррогатными ключами, и единственным недостатком было отсутствие денормализованных данных для разделения.

Большинство традиционных разработчиков PL / SQL, с которыми я работал, не любили суррогатные ключи из-за количества таблиц на соединение, но наши тестовые и производственные базы данных никогда не вызывали беспокойства; дополнительные соединения не повлияли на производительность приложения. С диалектами базы данных, которые не поддерживают такие предложения, как «внутреннее соединение X Y на Xa = Yb», или разработчиками, которые не используют этот синтаксис, дополнительные соединения для суррогатных ключей действительно затрудняют чтение запросов, их более длительный ввод и проверьте: см. сообщение @Tony Andrews. Но если вы используете ORM или любой другой фреймворк для генерации SQL, вы этого не заметите. Слепой набор также смягчает.

Может быть, это не совсем относится к этой теме, но суррогатные ключи у меня головная боль. Предварительно поставленная аналитика Oracle создает автоматически сгенерированные SK для всех своих таблиц измерений на складе, а также сохраняет их на основе фактов. Таким образом, каждый раз, когда их (измерения) необходимо перезагружать по мере добавления новых столбцов или их заполнения для всех элементов в измерении, SK, назначенные во время обновления, не синхронизируют SK с исходными значениями, сохраненными в факте, что вынуждает полная перезагрузка всех присоединяющихся к нему таблиц фактов. Я бы предпочел, чтобы даже если бы SK был бессмысленным числом, был бы какой-то способ, которым он не мог измениться для исходных / старых записей. Как многие знают, готовые решения редко удовлетворяют потребности организации, и мы должны постоянно настраиваться. Теперь у нас в хранилище есть данные за 3 года, и полная перезагрузка из финансовых систем Oracle очень велика. Так что в моем случае они не создаются на основе ввода данных, а добавляются в хранилище, чтобы помочь в отчетности производительности. Я понимаю, но наши действительно меняются, и это кошмар.