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

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

Я собирался придерживаться значения по умолчанию и использовать в качестве первичного ключа значение auto-incrementing integer, но пока один поставщик поставляет свое собственное поле "ProductiD", остальные не делают этого, и мне придется делать много ручного сопоставления к другим таблицам, чтобы загрузить данные (так как я должен был сначала загрузить его в таблицу "Продукты", затем вытащить идентификатор и добавить его вместе с другой информацией, необходимой мне для других таблиц).

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

Любые идеи, над которыми я должен смотреть?

Ответ 1

Это выбор между суррогатными и естественными первичными ключами.

ИМХО всегда предпочитают суррогатные первичные ключи. Первичные ключи не должны иметь значения, поскольку это значение может измениться. Даже названия стран могут измениться, и страны могут возникнуть и исчезнуть, не говоря уже о продуктах. Изменение первичных ключей определенно не рекомендуется, что может происходить с естественными клавишами.

Подробнее о суррогатное и первичные ключи:

Значит, суррогатные ключи выигрывают? Что ж, позволяет просмотреть и посмотреть, минусы естественных ключей применяются к суррогатные ключи:

Con 1: размер первичного ключа - суррогатные ключи обычно не имеют проблем с размером индекса, поскольку они обычно один столбец типа int. Это примерно так же мало.

Con 2: размер внешнего ключа - у них нет внешнего ключа или иностранного проблемы с размерами индекса либо для по той же причине, что и Con 1.

Con 3: Asthetics - Ну, это глаз вещи типа смотрителя, но они, конечно, не требуют письменного столько же кода, как со сложным естественным ключи.

Con 4 и 5: Опциональность и применимость - Суррогатные ключи не имеют проблемы с людьми или желая или не в состоянии предоставить данные.

Con 6: Уникальность - на 100% гарантировано быть уникальным. Это рельеф.

Con 7: Конфиденциальность. У них нет проблем с конфиденциальностью, если недобросовестные лица получают их.

Con 8: Случайная денормализация - вы не можете случайно денормализовать нерабочие данные.

Con 9: Каскадные обновления - Суррогатные ключи не меняются, поэтому нет заботы о том, как их каскадировать обновление.

Con 10: скорость присоединения Varchar - они обычно являются int, поэтому они обычно как быстро, чтобы присоединиться, как вы можете получить.

А также Суррогатные ключи или натуральные ключи для основного ключа?

Ответ 2

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

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

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

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

DECLARE @Key INT

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

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

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

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

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

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

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

Ответ 3

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

Из моего личного опыта работы с уникальными каналами данных SKU и поставщиков - вы абсолютно уверены, они отправляют вам фид с полными уникальными, хорошо сформированными SKU

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

В конце я пошел с автоинкрементным ПК.

Ответ 7

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

Ответ 8

Суррогатный ключ (поле автоматического инкремента INT) однозначно идентифицирует строку в таблице. С другой стороны, уникальный ключ Natural (productName) предотвратит вход в таблицу данных о повторяющихся продуктах.

С уникальным полем Natural key, две или более строк никогда не могут иметь одинаковые данные.

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

Давайте возьмем пример таблицы User, поле Natural key (userName) таблицы запретит тому, чтобы один и тот же пользователь дважды регистрировался, но поле автоматического увеличения INT (userId) не будет.

Ответ 9

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

Ответ 10

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

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