Является основным ключом, необходимым в SQL Server?

Question

Это может быть довольно наивный и глупый вопрос, но я все равно его спрошу

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

Эту таблицу можно получить через неисторические поля регулярно, но без доступа к пользовательскому SP или доступу к процессу через первичный ключ. Нужен ли первичный ключ? Используется ли он за кулисами? Удаляет ли это влияние на результат Позитивно или Отрицательно?

Answer 1

Необходимо? Нет. Используется за кулисами? Ну, он сохраняется на диске и хранится в кеше строк и т. Д. Удаление немного увеличит вашу производительность (используйте часы с миллисекундной точностью, чтобы заметить).

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

Заключение: Поскольку стоимость наличия ПК (даже если он не используется ATM) настолько мал, пусть это будет.

Answer 2

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

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

Answer 3

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

Answer 4

A PK не требуется.

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

HTH!
Thomas

Answer 5

Если вы обращаетесь к ним через неблокируемые поля, производительность, вероятно, не изменится. Однако было бы неплохо сохранить PK для будущих улучшений или интерфейсов для этих таблиц. Использует ли ваше приложение только эту таблицу?

Answer 6

Первичный ключ находится за кулисами a clustered index (по умолчанию, если он не сгенерирован как некластеризованный индекс) и содержит все данные для таблицы. Если PK является столбцом идентификации, вставки будут выполняться последовательно, и никакие разбиения страниц не будут происходить.

Но если вы вообще не обращаетесь к столбцу id, вы, вероятно, захотите добавить некоторые индексы в другие столбцы. Также, когда у вас есть ПК, вы можете настроить отношения FK.

Answer 7

Как сказал SQLMenace, кластеризованный индекс является важным столбцом для физического расположения таблицы. Кроме того, наличие кластеризованного индекса, особенно хорошо выбранного на тонком столбце, таком как целое число pk, фактически увеличивает производительность вставки.

Answer 8

Есть ли у вас какие-либо внешние ключи, вы когда-нибудь присоединяетесь к ПК?

Если ответ на этот вопрос отсутствует, и ваше приложение никогда не извлекает элемент из таблицы его ПК, и ни один запрос никогда не использует его в предложении where, поэтому вы просто добавили столбец IDENTITY, чтобы иметь PK, тогда :

• рК в себе не добавляет ценности, но не делает никаких повреждений ни
• тот факт, что PK весьма вероятно, кластерный индекс тоже есть .. это зависит.

Если у вас есть индексы NC, то тот факт, что у вас есть узкий искусственный кластерный ключ (Идентичность PK) помогает в сохранении этих индексов сужать (ключ CDX воспроизводится в каждом слотами листьев NC). Таким образом, ПК, даже если он никогда не используется, полезен, если у вас есть значительные индексы NC.

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

И, наконец, если таблица редко запрашивается, но часто записывается в нее, это может быть хорошим кандидатом для HEAP (без кластерного ключа вообще), так как кучи намного лучше вставляются. См. Comparing Tables Organized with Clustered Indexes versus Heaps.

Answer 9

Первичный ключ действительно является свойством вашей модели домена и однозначно идентифицирует экземпляр объекта домена.

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

У меня есть веская причина для создания таблицы без первичного ключа.

Answer 10

В логической модели таблица должна иметь хотя бы один ключ. Нет причин для арбитражного определения того, что один из ключей является «основным»; все ключи равны. Хотя понятие «первичный ключ» можно проследить до ранней работы Теда Кодда, ошибка была поднята на ранней стадии уже давно исправлена ​​в реляционной теории.

К сожалению, PRIMARY KEY нашел, что это путь в SQL, и с тех пор нам пришлось жить с ним. Таблицы SQL могут иметь повторяющиеся строки и, если вы считаете, что набор результатов запроса SELECT также является таблицей, то таблицы SQL также могут иметь дублирующие строки. Теоретики отношения не очень любят SQL. Тем не менее, только потому, что SQL позволяет вам делать всевозможные дурацкие нереляционные вещи, это не значит, что вы должны их действительно делать. Является хорошей практикой, чтобы каждая таблица SQL имела хотя бы один ключ.

В SQL, используя PRIMARY KEY сам по себе, имеет значение, например. NOT NULL, UNIQUE, ссылка по умолчанию для внешних ключей. В SQL Server использование PRIMARY KEY само по себе имеет последствия, например. кластеризованный индекс таблицы. Однако во всех этих случаях неявное поведение можно сделать явным, используя специальный синтаксис.

Вы можете использовать UNIQUE (ограничение, а не индекс) и NOT NULL в сочетании с принудительным применением ключей в SQL. Поэтому нет, первичный ключ (или даже PRIMARY KEY) не требуется в SQL Server.