Необходим ли первичный ключ в SQL Server?

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

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

ПК не требуется.

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

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

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

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

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

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

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

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

К сожалению, 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 не нужен.

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

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

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

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

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

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

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

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