В настоящее время я разрабатываю совершенно новую базу данных. В школе мы всегда учились размещать первичный ключ в каждой таблице.
Я прочитал много сообщений о статьях/дискуссиях/новостных группах, в которых говорилось, что лучше использовать уникальное ограничение (также уникальный индекс для некоторого db) вместо PK.
Какова ваша точка зрения?
Можете ли вы предоставить ссылки на эти статьи?
Я не вижу причин менять проверенные и проверенные методы. В конце концов, первичные ключи являются фундаментальной конструктивной особенностью реляционных баз данных.
Использование UNIQUE для того, чтобы служить одной и той же цели, звучит для меня очень хакерски. Каково их обоснование?
Изменить: Мое внимание только что обратилось к этому старому ответу. Возможно, дискуссия, которую вы прочитали относительно ПК против UNIQUE, касалась людей, делающих что-то ПК исключительно с целью обеспечения уникальности на нем. Ответ на это: если это ключ, тогда сделайте его ключом, иначе сделайте его УНИКАЛЬНЫМ.
Первичный ключ - это просто ключ кандидата, который не допускает NULL. Таким образом, в терминах SQL - это не отличается от любого другого уникального ключа.
Однако для наших нетеоретических РСУБД у вас должен быть первичный ключ - я никогда не слышал, чтобы он утверждал иначе. Если этот первичный ключ является суррогатным ключом, то вы также должны иметь уникальные ограничения на естественный ключ (ы).
Важный бит, чтобы уйти, состоит в том, что у вас должны быть уникальные ограничения для всех кандидатов (независимо от того, являются ли они естественными или суррогатными). Затем вы должны выбрать тот, который легче всего ссылается в Foreign Key на ваш основной ключ *.
У вас также должен быть кластеризованный индекс *. это может быть ваш Первичный ключ или естественный ключ, но это тоже не требуется. Вы должны выбрать свой кластерный индекс, основанный на использовании запроса в таблице. Если у вас есть сомнения, первичный ключ не является плохим первым выбором.
Хотя технически требуется только ссылаться на уникальный ключ в отношении внешнего ключа, он принял стандартную практику, чтобы в значительной степени поддержать первичный ключ. На самом деле, я не удивлюсь, если некоторые РСУБД допускают только ссылки на первичные ключи.
Изменить: Было указано, что термин Oracle "кластерная таблица" и "кластеризованный индекс" отличаются от Sql Server. В Oracle-ese эквивалент того, что я говорю, это Index Ordered Table, и это рекомендуется для таблиц OLTP - что, я думаю, будет основным направлением SO-вопросов. Я предполагаю, что если вы несете ответственность за большой хранилище данных OLAP, у вас уже должно быть свое мнение о дизайне и оптимизации базы данных.
Первичный ключ - это только ключ-кандидат (уникальное ограничение), выделенное для специального лечения (автоматическое создание индексов и т.д.).
Я ожидаю, что люди, которые спорят с ними, не видят причин рассматривать один ключ иначе, чем другой. Это, где я стою.
[Изменить] По-видимому, я не могу прокомментировать даже мой собственный ответ без 50 баллов.
@chris: Я не думаю, что там какой-то вред. "Первичный ключ" - это действительно просто синтаксический сахар. Я использую их все время, но я, конечно, не думаю, что они требуются. Требуется уникальный ключ, да, но необязательно Первичный ключ.
Это будет очень редкая денормализация, которая заставит вас хотеть иметь таблицу без первичного ключа. Первичные ключи имеют уникальные ограничения автоматически по своей природе как ПК.
Единственное ограничение будет использовано, если вы хотите гарантировать уникальность в столбце ADDITION для первичного ключа.
Правило всегда иметь PK является хорошим.
Вы должны всегда иметь первичный ключ.
Тем не менее, я подозреваю, что ваш вопрос просто сформулирован как бит, вводящий в заблуждение, и вы действительно хотите спросить, должен ли первичный ключ всегда быть автоматически сгенерированным числом (также называемым суррогатным ключом) или некоторым уникальным полем, являющимся актуальными значимыми данными (также известный как естественный ключ), как SSN для людей, ISBN для книг и т.д.
Этот вопрос - вековая религиозная война в области БД.
Я считаю, что естественные ключи предпочтительнее, если они действительно уникальны и никогда не меняются. Тем не менее, вы должны быть осторожны, даже что-то, казалось бы, стабильное, как люди, которых SSN может измениться при определенных обстоятельствах.
Первичные ключи должны использоваться в ситуациях, когда вы будете устанавливать отношения из этой таблицы в другие таблицы, которые будут ссылаться на это значение. Тем не менее, в зависимости от характера таблицы и данных, к которым вы привыкли применять уникальное ограничение, вы можете использовать это конкретное поле как естественный первичный ключ, а не устанавливать суррогатный ключ. Конечно, суррогат против естественных ключей - это еще одно обсуждение.:)
Уникальные ключи могут использоваться, если между этой таблицей и другими таблицами не будет установлено никаких отношений. Например, таблица, содержащая список действительных адресов электронной почты, которые будут сопоставлены до ввода новой пользовательской записи или некоторых таких. Или уникальные ключи могут использоваться, когда у вас есть значения в таблице с первичным ключом, но также должны быть абсолютно уникальными. Например, если у вас есть таблица пользователей с именем пользователя. Вы не хотели бы использовать имя пользователя в качестве первичного ключа, но он также должен быть уникальным, чтобы он мог использоваться для входа в систему.
Если таблица не является временной таблицей для обработки данных во время работы над ней, вы всегда хотите поместить первичный ключ в таблицу, и вот почему:
1 - единственное ограничение может допускать нулевые значения, но первичный ключ никогда не допускает null. Если вы запускаете запрос с объединением в столбцах с нулевыми значениями, вы удаляете эти строки из результирующего набора данных, поскольку null не равен нулю. Таким образом, даже крупные компании могут делать ошибки учета и должны пересчитывать свою прибыль. Их запросы не отображали определенные строки, которые должны были быть включены в итоговое значение, потому что в некоторых столбцах их уникального индекса были нулевые значения. Shoulda использовал первичный ключ.
2 - уникальный индекс будет автоматически помещен в первичный ключ, поэтому вам не нужно его создавать.
3 - большинство движков базы данных автоматически помещают кластерный индекс в первичный ключ, делая запросы быстрее, потому что строки хранятся смежно в блоках данных. (Это можно изменить, чтобы поместить кластеризованный индекс в другой индекс, если это ускорит запросы.) Если таблица не имеет кластерного индекса, строки не будут храниться смежно в блоках данных, делая запросы медленнее, потому что голова чтения/записи должна перемещаться по всему диску для сбора данных.
4 - для многих сред разработки интерфейса требуется первичный ключ для обновления таблицы или удаления.
Нам нужно провести различие между логическими конструкциями и физическими конструкциями и аналогично между теорией и практикой.
Для начала: с теоретической точки зрения, если у вас нет первичного ключа, у вас нет таблицы. Это просто так просто. Итак, ваш вопрос заключается не в том, должен ли ваша таблица иметь первичный ключ (конечно, это должно быть), а как вы помещаете его в свои РСУБД.
На физическом уровне большинство РСУБД реализуют ограничение первичного ключа как уникальный индекс. Если ваша выбранная СУБД является одной из них, то, вероятно, не так много практической разницы между обозначением столбца как основного ключа и просто помещением уникального ограничения на столбец. Однако: один из этих вариантов фиксирует ваши намерения, а другой - нет. Таким образом, решение без проблем.
Кроме того, некоторые РСУБД предоставляют дополнительные функции, если Первичные ключи должным образом помечены, такие как диаграмма и полуавтоматическая поддержка ограничения внешнего ключа.
Любой, кто советует вам использовать уникальные ограничения вместо первичных ключей в качестве общего правила, должен обеспечить довольно простую причину.
дело в том, что первичным ключом может быть один или несколько столбцов, которые однозначно идентифицируют одну запись таблицы, где Unique Constraint является просто ограничением для поля, которое допускает только один экземпляр любого данного элемента данных в Таблица.
ЛИЧНО. Я использую либо GUID, либо auto-incrementing BIGINTS (Identity Insert для SQL SERVER) для уникальных ключей, используемых для перекрестных ссылок среди моих таблиц. Затем я буду использовать другие данные, чтобы пользователь мог выбирать определенные записи.
Например, у меня будет список сотрудников и есть GUID, прикрепленный к каждой записи, которую я использую за кулисами, но когда пользователь выбирает сотрудника, они выбирают их на основе следующих полей: LastName + FirstName + EmployeeNumber.
Моим первичным ключом в этом сценарии является LastName + FirstName + EmployeeNumber, а уникальный ключ - связанный GUID.
сообщения говорят, что лучше использовать уникальное ограничение (также уникальный индекс для некоторого db) вместо PK
Я думаю, что единственная точка здесь - это то же самое старое обсуждение "естественные против суррогатных ключей", потому что уникальные индексы и pk'ы - одно и то же.
перевод:
сообщения говорят, что лучше использовать естественный ключ вместо суррогатного ключа
Обычно я использую как PK, так и UNIQUE KEY. Потому что, даже если вы не укажете PK в своей схеме, вы всегда создаете для себя внутренне. Это верно как для SQL Server 2005, так и для MySQL 5.
Но я не использую столбец PK в своих SQL. Это для целей управления, таких как УДАЛЕНИЕ некоторых ошибочных строк, выяснение пробелов между значениями PK, если оно установлено в AUTO INCREMENT. И имеет смысл иметь PK в виде чисел, а не набор столбцов или char массивов.
Я много писал на эту тему: если вы прочтете что-нибудь, я буду ясно, что, вероятно, я имею в виду, в частности, доступ к Jet a.k.a. MS Access.
В Jet таблицы физически упорядочены в PRIMARY KEY с использованием неупорядоченного кластеризованного индекса (кластер на компактном). Если таблица не имеет PK, но имеет ключи кандидата, определенные с помощью ограничений UNIQUE на столбцах NOT NULL, тогда движок будет выбирать один для кластерного индекса (если в вашей таблице нет кластерного индекса, то он называется кучей, возможно, не является таблицей вообще!) Как двигатель выбирает ключ кандидата? Может ли он выбрать тот, который включает в себя столбцы с нулевым значением? Я действительно не знаю. Дело в том, что в Jet единственный явный способ указать кластерный индекс для движка - использовать PRIMARY KEY. Разумеется, для ПК в Jet, например, есть другие способы использования. он будет использоваться в качестве ключа, если он исключен из объявления FOREIGN KEY в SQL DDL, но опять же, почему бы не быть явным.
Проблема с Jet заключается в том, что большинство людей, создающих таблицы, не знают или не заботятся о кластеризованных индексах. Фактически, большинство пользователей (я ставлю) помещают столбец Autonumber автоинкремента в каждую таблицу и определяют PRIMARY KEY исключительно в этом столбце, не создавая никаких уникальных ограничений для ключа естественного ключа и кандидата (можно ли фактически считать столбец автоинкремента ключ, не подвергая его конечным пользователям, - это еще одна дискуссия сама по себе). Я не буду вдаваться в подробности о кластеризованных индексах здесь, но достаточно сказать, что IMO - единственный столбец автоинкремента, редко подходит для идеального выбора.
Независимо от того, какой вы SQL-движок, выбор PRIMARY KEY произволен и зависит от двигателя. Обычно двигатель будет придать особое значение ПК, поэтому вы должны выяснить, что это такое, и использовать его в своих интересах. Я призываю людей использовать NOT NULL UNIQUE ограничения в надежде, что они будут уделять больше внимания всем ключам-кандидатам, особенно когда они решили использовать столбцы "autonumber", которые (должны) не имеют смысла в модели данных. Но я предпочел бы, чтобы народ выбрал один хорошо рассмотренный ключ и использовал PRIMARY KEY вместо того, чтобы поместить его в колонку автоинкремента по привычке.
Должны ли все таблицы иметь ПК? Я говорю "да", потому что в противном случае, по крайней мере, вы теряете небольшое преимущество, которое дает ПК, и в худшем случае у вас нет целостности данных.
BTW Chris OC делает здесь хороший момент о временных таблицах, для которых требуются первичные ключи с первичными ключами (строчные буквы), которые не могут быть реализованы с помощью простых ограничений PRIMARY KEY (ключевые слова SQL в верхнем регистре).
ПЕРВИЧНЫЙ КЛЮЧ
1. Null Он не позволяет значения Null. Из-за этого мы обращаемся к PRIMARY KEY = УНИКАЛЬНЫЙ КЛЮЧ + НЕ НЕВЕРНЫЙ КОНСТРУКЦИЯ. 2. INDEX По умолчанию он добавляет кластерный индекс. 3. LIMIT Таблица может иметь только одну колонку PRIMARY KEY [s].
УНИКАЛЬНЫЙ КЛЮЧ
1. Null Позволяет указать значение Null. Но только одно значение Null. 2. INDEX По умолчанию он добавляет UNIQUE некластеризованный индекс. 3. LIMIT В таблице может быть несколько UNIQUE ключевых столбцов [s].
Если вы планируете использовать LINQ-to-SQL, ваши таблицы потребуют Первичные ключи, если вы планируете выполнять обновления, и для них потребуется столбец timestamp, если вы планируете работать в отключенной среде (например, объект через приложение службы WCF).
Если вам нравятся .NET, PK и FK - ваши друзья.
Я утверждаю, что вам могут понадобиться оба. Первичные ключи по своей природе должны быть уникальными и не подлежащими обнулению. Они часто являются суррогатными ключами, поскольку целые числа создают более быстрое объединение, чем символы, и особенно, чем множественные объединения полей. Однако, поскольку они часто генерируются автоматически, они не гарантируют уникальность записи данных, исключая сам идентификатор. Если в вашей таблице есть естественный ключ, который должен быть уникальным, у вас должен быть уникальный индекс для предотвращения ввода данных дубликатов. Это базовое требование целостности данных.
Отредактировано для добавления: Это также реальная проблема, что данные реального мира часто не имеют естественного ключа, который действительно гарантирует уникальность в нормализованной структуре таблицы, особенно если база данных сосредоточена на людях. Имена, даже имя, адрес и номер телефона вместе (думаю, отец и сын в той же медицинской практике) не обязательно уникальны.
Я думал об этой проблеме. Если вы используете уникальную, вы повредите 2. NF. В соответствии с этим каждый атрибут non-pk должен быть в зависимости от ПК. Пара атрибутов в этом уникальном ограничении должна рассматриваться как часть ПК.
жаль, что ответила на это 7 лет спустя, но не хотела начинать новое обсуждение.