Команда, с которой я работаю, решила создать таблицу с первичным ключом varchar. На эту таблицу ссылается другая таблица этого первичного ключа.
У меня есть привычка создавать целостный первичный ключ, следуя тому, что я узнал в университете. Я прочитал, что есть увеличение производительности с использованием целочисленного первичного ключа.
Дело в том, что я не знаю другой причины для создания целочисленного первичного ключа. У вас есть советы?
Первичный ключ должен представлять идентификатор строки и не должен меняться со временем.
Я предполагаю, что varchar - это своего рода естественный ключ - например, имя объекта, адрес электронной почты или серийный номер. Если вы используете естественный ключ, иногда бывает, что ключ должен измениться, например:
Используя ключ суррогата, вы избегаете проблем, связанных с изменением первичных ключей.
VARCHAR против INT мало что говорит. Какое значение имеет шаблон доступа.
В абсолютном выражении более широкий ключ всегда будет хуже, чем узкий ключ. Тип не имеет абсолютно никакого значения, имеет значение ширина. По сравнению с INT, однако, немногие типы могут превзойти INT в узости, поэтому INT обычно побеждает этот аргумент только благодаря тому, что его ширина составляет всего 4 байта.
Но что действительно важно, так это выбор кластерного ключа. Часто путают с первичным ключом, оба представляют разные понятия и не обязаны перекрываться. Вот более подробное обсуждение Должен ли я создавать таблицу с первичным ключом varchar или int? Выбор кластеризованного ключа - это почти самое важное решение в дизайне таблицы и механическое применение INT identity(1,1), может быть, это самая большая ошибка, которую можно сделать. Здесь возникает вопрос о моделях доступа:
В целом, существует много шаблонов доступа, которые можно разрушить с помощью кластерного ключа INT IDENTITY. Поэтому, прежде чем приступить к применению решения для формочки печенья, возможно, потребуется немного проанализировать...
Некоторые более общие рекомендации:
Вы видите, что нет никаких рекомендаций по проектированию Первичного ключа, потому что Первичный ключ - это не проблема проектирования хранилища, а проблема моделирования и полностью зависит от домена.
Я был немного разочарован, потому что я привычка создавать целые первичные ключ (после того, что сказал какой-то учитель меня в университете). Я много читал документации по эффективности boost с использованием целочисленного первичного ключа.
Существует термин для этого: подтверждение смещения:
", также называемый подтверждающим уклоном или смещением мышления) - это склонность людей поддерживать информацию, подтверждающую их предубеждения или гипотезы, независимо от того, являются ли они истинными. Это приводит к тому, что люди выборочно собирают новые доказательства, интерпретируя доказательства в предвзятом ключе, или выборочного вызова информации из памяти."
Конечно, ваша первая реакция будет состоять в том, чтобы сказать: "Но это не так!" Да, вы могли бы сказать, что "потому что вы предвзяты;" [язык прочно вложен в щеку]
Вот классический пример: скажите, что вы сказали своему зоологическому профессору, что все лебеди белые и, конечно же, все лебеди, которые вы и ваши друзья когда-либо встречали, белые. Теперь позвольте сказать, что позже в жизни коллега выразил мнение, что, возможно, существует такое существо, как черный лебедь. Какие?! Это не то, чему вас учили. Ваш мир потрясен! Вы немедленно выходите и проводите лебединое обследование, и вы считаете 1000 белых лебедей и нулевых черных лебедей. Доказательство! Если бы вы нашли 10 000 белых лебедей, то гипотеза "Все лебеди белые" будет в десять раз вернее, не так ли?
Другой подход состоял бы в том, чтобы забыть о белых лебедях на данный момент и попытаться найти черного лебедя. Возможно, возьмите отпуск у моря в солнечном свете Dawlish?Я действительно не хочу звучать неуважительно; вы признаете, что читаете много о том, что вам сказали, и это действительно заслуживает моего уважения. Итак, вот вызов: попробуйте найти случаи, когда добавление целочисленного столбца в таблицу не нужно.
Вот некоторые подсказки и спойлеры: таблицы, на которые не ссылаются другие таблицы; таблицы с одним столбцом "все ключевые"; "маленькие" таблицы, которые не запрашиваются много:)
Вот некоторые другие связанные темы, которые вы можете исследовать:
Значит ли слово "primary" в "primary key" многозначительно или все ключи в данной таблице равны?
Каковы качества "хорошего" ключа? (например, если ключевые значения являются неизменяемыми или достаточно "хорошими"?)
Является ли целочисленный столбец, добавленный в таблицу как искусственный ключ (perhpas, потому что доступный естественный ключ недостаточно "хорош" ) или как суррогатный ключ (возможно, для повышения производительности "хорошего" естественного ключа)?
Когда суррогатный ключ добавляется к таблице по показателям эффективности, это для фактического измеренного эффекта или просто для воспринимаемого эффекта (то есть преждевременной оптимизации)?
Должны ли суррогатные ключи появляться в логической бизнес-модели или они предназначены только для реализации?
Хорошо ли всегда что-то делать (например, добавлять целочисленный столбец в таблицу) без привлечения мозга каждый раз?;)
[Отказ от ответственности: я сторонник естественного ключевого слова и избегаю суррогатов. Для меня они похожи на денормализацию: вы делаете это только тогда, когда это необходимо, как правило, для проблемы с производительностью (конкретной и доказуемой), где ошибка лежит где-то в другом месте (отвратительная версия SQL-продукта, недостаток логического дизайна, который в настоящее время не может быть исправлен и т.д.).). Суррогаты никогда не должны появляться в логической бизнес-модели. Мне иногда нужен искусственный идентификатор и даже выставлял им логические бизнес-модели.]