Решение между искусственным первичным ключом и естественным ключом для таблицы продуктов

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

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

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

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

DECLARE @Key INT

UPDATE  KeyTable
WITH    (rowlock)
SET @Key = LastKey = LastKey + 1
WHERE   KeyType = 'Product'

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

Почему следует избегать буквенно-цифровых первичных ключей:

Три основные проблемы: производительность, сопоставление и пространство.

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

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

Пробел - код из девяти символов, такой как у David, занимает девять байт, а целое - только четыре (2 для smallint, 1 для tinyint). Даже bigint занимает всего 8 байтов.

Когда-либо непосредственная опасность с естественными ключами состоит в том, что или Ваши начальные предположения будут доказаны неправильными теперь или в будущем, когда некоторое изменение будет внесено вне Вашего управления, или в некотором месте необходимо будет сослаться на запись, где передача значимого поля не желаема (напр. веб-приложение, которое использует номер социального страхования сотрудника в качестве первичного ключа и затем должно использовать URL как/employee.php? ssn=xxxxxxx)

От моего собственного личного опыта с "уникальным" SKU's и подача данных поставщика - Вы абсолютно уверенный , они отправляют Вам канал с полным, уникальным, хорошо сформированными наименованиями?

я должен был лично иметь дело со всеми следующими при получении подачи от поставщиков, у которых есть переменные уровни IT и конторской компетентности:

• продукты пропускают свой SKU полностью ("")
• , Клерки использовали наименования заполнителя в своей базе данных как 999999999 и 00000000 и никогда не исправляли их
• , Те, которые делают ввод данных или импорт, перепутали между различными номерами продуктов, перепутав вещи как UPC с SCC, или даже найдя способы исказить их вместе (я видел коды SCC с невозможными контрольными разрядами в конце, потому что они просто скопировали UPC и добавили 01 или 10, не исправляя контрольный разряд)
• Для особых причин или просто некомпетентности, поставщик ввел тот же продукт дважды в их базу данных (например, версия. 1 и версия. 2 из той же материнской платы имеют тот же SKU, но существуют как 2 записи в базе данных поставщиков и канале данных потому что версия 2. имеет новые возможности)

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

Я был бы совет относительно наличия автоувеличенного "бессмысленного" целого числа как первичный ключ. Если кто-то придумывает идею реорганизовать идентификаторы продукта, по крайней мере, Ваш DB не попадет в беду.

Очень похоже на мой вопрос несколько месяцев назад ...

Должен ли я иметь специальное поле первичного ключа?

Я пошел с автоматическим увеличением PK в конце.

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

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

Вы всегда можете взять хеш SKU, который бы избавился от альф. Вам придется кодировать для возможных коллизий (что должно быть очень редко), что является дополнительным осложнением.

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