У меня есть таблица с четырьмя столбцами, которые не обнуляются, и данные таковы, что все четыре необходимы для различения уникальной записи. Это означает, что если бы я должен был создать первичный ключ, он должен был бы включать все столбцы. Запросы к таблице почти всегда будут сводиться к одной записи, то есть все столбцы будут отфильтрованы в запросе.
Так как каждый столбец нужно будет искать, будет ли мне полезно иметь первичный ключ (помимо обеспечения уникальности записей)?
Ответы:
В вашем случае эти поля являются естественным ключом.
Суррогатный ключ:
Суррогатные ключи - это ключи, которые не имеют «делового» значения и используются исключительно для идентификации записи в таблице. Такими ключами являются либо сгенерированные базой данных (например: Identity в SQL Server, Sequence в Oracle, Sequence / Identity в DB2 UDB и т. Д.), Либо сгенерированные системой значения (например, сгенерированные с помощью таблицы в схеме).
Естественный Ключ:
Ключи являются естественными, если представленный им атрибут используется для идентификации независимо от схемы базы данных. В основном это означает, что ключи являются естественными, если люди используют их, например: счета-фактуры, налоговые идентификаторы, SSN и т. Д.
Суррогатные ключи против естественных ключей для первичного ключа
Я предпочитаю добавлять суррогатный ключ для управления бизнес-моделями и базами данных. Другой вопрос заключается в использовании кластерного и некластеризованного индекса по первичному ключу. Если вы вносите изменения в таблицу (нестатическая таблица с интенсивными вставками или обновлениями), у вас возникнут проблемы с производительностью в случае использования кластерного индекса по немонотонному увеличенному ключу.
Обычно в таких ситуациях рекомендуется иметь суррогатный ключ, поэтому внешние ключи в других таблицах (и любые ссылки на записи, которые могут храниться извне, например, если они переносятся на строки запроса, где запрос http (s) ссылается на один записей), на которые можно сослаться, которые не изменятся, если данные в строке изменятся. Если вы сделаете это, то это будет ваш первичный ключ.
Если вы не добавите такой суррогатный ключ, то, учитывая то, как вы описываете данные, к которым осуществляется доступ, имея все четыре столбца в качестве первичного ключа, не будет недостатком. Если вы сделаете ключ кластеризованным индексом для таблицы, это поможет таким запросам, поскольку в b-дереве на диске будет один уровень вниз, чтобы найти данные для данной строки.
Составные ключи в качестве первичных ключей также сталкиваются с проблемами размера индекса, которые могут повлиять на использование диска, скорость ввода-вывода и резервное копирование. Вы можете просмотреть сообщения Кимберли Триппа о первичных ключах и кластерных индексах здесь: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx
Я бы тоже предложил в этом случае суррогатный ключ вместо обычного.
Если у вас есть таблица, представляющая отношение «многие ко многим», которая имеет всего 2 столбца, это кажется разумным.
Но я признаю, что я добавляю суррогатные ключи даже в тех случаях.