Это может быть довольно наивный и глупый вопрос, но я все равно его спрошу
У меня есть таблица с несколькими полями, ни одна из которых не является уникальной, и первичный ключ, который, очевидно, есть.
Эту таблицу можно получить через неисторические поля регулярно, но без доступа к пользовательским SP или данным процесса через первичный ключ. Нужен ли первичный ключ? Используется ли он за кулисами? Удаляет ли это влияние на результат Позитивно или Отрицательно?
нужно? Нет. Используется за кулисами? Ну, он сохраняется на диске и хранится в кеше строк и т.д. Удаление немного увеличит вашу производительность (используйте часы с миллисекундной точностью, чтобы заметить).
Но... в следующий раз, когда кому-то нужно будет создать ссылки на эту таблицу, они будут проклинать вас. Если они храбрые, они добавят PK (и ожидают, что DB создаст столбец). Если они не являются храбрыми или немыми, они начнут создавать ссылки с использованием бизнес-ключа (то есть столбцов данных), что приведет к кошмару обслуживания.
Заключение: поскольку стоимость наличия ПК (даже если он не используется ATM) настолько мал, пусть это будет.
Есть ли у вас какие-либо внешние ключи, вы когда-нибудь присоединяетесь к ПК?
Если ответ на этот вопрос отрицательный, и ваше приложение никогда не извлекает элемент из таблицы по его PK, и ни один запрос никогда не использует его в предложении where, поэтому вы просто добавили столбец IDENTITY для PK, а затем:
Если у вас есть индексы NC, то тот факт, что у вас есть узкий искусственный кластеризованный ключ (IDENTITY PK), полезен для того, чтобы эти индексы были узкими (CDX-ключ воспроизводится в каждом слоте листа NC). Таким образом, ПК, даже если он никогда не используется, полезен, если у вас есть значительные индексы NC.
С другой стороны, если у вас распространенный шаблон доступа, то определенный запрос, который перевешивает все остальные, является частотой и значением или является частью критического кода временного кода (например, выполняется запрос на каждом посещении страницы на вашем сайте или каждую секунду, и т.д. и т.д.), то этот запрос является хорошим кандидатом для диктовки кластеризованного порядка ключей.
И, наконец, если таблица редко запрашивается, но часто записывается, то она может быть хорошим кандидатом для HEAP (без кластерного ключа вообще), так как кучи намного лучше вставляются. См. Сравнение таблиц, организованных с помощью кластеризованных индексов против кучи.
Первичный ключ находится за кулисами a clustered index (по умолчанию, если он не сгенерирован как некластеризованный индекс) и содержит все данные для таблицы. Если PK является столбцом идентификации, вставки будут выполняться последовательно, и никакие разбиения страниц не будут происходить.
Но если вы вообще не обращаетесь к столбцу id, вы, вероятно, захотите добавить некоторые индексы в другие столбцы. Также, когда у вас есть ПК, вы можете настроить отношения FK
В логической модели таблица должна содержать как минимум один ключ. Нет причин для арбитражного определения того, что один из ключей является "основным"; все ключи равны. Хотя понятие "первичный ключ" можно проследить до ранней работы Теда Кодда, ошибка была поднята на ранней стадии уже давно исправлена в реляционной теории.
К сожалению, 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.
У меня никогда не было бы таблицы без первичного ключа. Предположим, вам нужно удалить дубликат - как бы вы определили, какой из них удалить и который сохранить?
Первичный ключ, если он определен, поможет повысить производительность в базе данных для индексирования и отношений.
Я всегда стараюсь определить первичный ключ как автоматически увеличивающееся целое во всех моих таблицах, независимо от того, обращаюсь к нему или нет, потому что, когда вы начинаете расширять свое приложение, вы можете обнаружить, что вам действительно нужно его, и это делает жизнь намного проще.
Первичный ключ действительно является свойством вашей модели домена и однозначно идентифицирует экземпляр объекта домена.
Наличие кластерного индекса в столбце, увеличивающем монотонность (например, столбец идентичности) будет означать, что разбиение на страницы не произойдет, НО вставки будут дисбаланс индекса во времени, и поэтому восстановление индексов должно выполняться регуляризированным (или когда фрагментация достигает определенный порог).
У меня есть очень веская причина для создания таблицы без первичного ключа.
A PK не требуется.
Но вы должны рассмотреть возможность размещения неидеального индекса в столбцах, которые вы используете для запросов (т.е. которые появляются в предложении WHERE). Это значительно повысит производительность поиска.
НТН!
Томас
Если вы обращаетесь к ним через не-ключевые поля, производительность, вероятно, не изменится. Однако было бы неплохо сохранить PK для будущих улучшений или интерфейсов для этих таблиц. Использует ли ваше приложение только эту таблицу?
Как сказал SQLMenace, кластеризованный индекс является важным столбцом для физического расположения таблицы. Кроме того, наличие кластеризованного индекса, особенно хорошо выбранного на тонком столбце, таком как целое число pk, фактически увеличивает производительность вставки.