Здравствуйте, vvu, Вы писали:
vvu>>>Еще, Первичный служит для организации ссылочной целостности. vvu>>>А Уникальный просто, чтобы значения поля (групп полей) не повторялись. V>>Не совсем так. Unique тоже может служить для ссылочной целостности, например, через unique может быть создан альтернативный ключ.
vvu>Согласен Но я думаю или даже читал где-то (скорее всего читал, а теперь думаю), что лучше (предпочтительнее) использовать PK. vvu>Кстати, про AK я вообще не очень понимаю, т.к. не приходилось сталкиваться. Я так думаю, что AK для ссылочной целостности, при наличии PK может понадобится использовать в какой-то ИСКЛЮЧИТЕЛЬНОЙ ситуации. А вот в какой? Я придумать не могу
Сходу вспоминаются два варианта использования из личной практики (хотя, случаи, конечно, не каждодневные).
Во-первых, ситуация одновременного использования первичных и альтернативных ключей для контроля ссылочной целостности может иметь место в промежуточном состоянии системы. Например, была сущность, у неё было ID, которое было PK. Потом оказалось, что ID может быть не уникально, поэтому был введён новый PK (IDENTITY). Так как система большая, то сразу её не переделать и сейчас используются оба ключа.
Второй вариант — интеграция двух систем, где в качестве PK используются разнве поля. При объединении таких систем запросто можно получить таболицу с полями типа PK_FromSystem1 и PK_FromSystem2, каждое из которых является PK для некоторого своего набора данных.
Здравствуйте, vvu, Вы писали:
vvu>Здравствуйте, artem2309, Вы писали:
A>>Подскажите в чем отличие primary key от unique?
vvu>Еще, Первичный служит для организации ссылочной целостности. vvu>А Уникальный просто, чтобы значения поля (групп полей) не повторялись.
Не совсем так. Unique тоже может служить для ссылочной целостности, например, через unique может быть создан альтернативный ключ.
Логически PRIMARY KEY это основной и в большинстве случаев единственный идентификатор записи.
Физически же отличия отлично описаны в MSDN:
--- MSDN ---
PRIMARY KEY Constraints
A table can contain only one PRIMARY KEY constraint.
Each PRIMARY KEY generates an index.
All columns defined within a PRIMARY KEY constraint must be defined as NOT NULL. If nullability is not specified, all columns participating in a PRIMARY KEY constraint have their nullability set to NOT NULL.
UNIQUE Constraints
Each UNIQUE constraint generates an index.
Здравствуйте, artem2309, Вы писали:
A>Подскажите в чем отличие primary key от unique?
Отличие между ними заключается в том, что ограничение UNIQUE допускает ввод неопределенных значений и генерирует некластерный индекс, тогда как в PRIMARY KEY не допускается использование неопределенных значений и используется кластерный индекс (физическая сортировка данных в порядке индекса).
Здравствуйте, Аноним, Вы писали:
А>Отличие между ними заключается в том, что ограничение UNIQUE допускает ввод неопределенных значений и генерирует некластерный индекс, тогда как в PRIMARY KEY не допускается использование неопределенных значений и используется кластерный индекс (физическая сортировка данных в порядке индекса).
СУБД-зависимо.
индексы — это уже способ реализации
основное:
1. как Вы и сказали, UQ допускает null
2. PK — один на таблицу
Здравствуйте, vvu, Вы писали:
vvu>Здравствуйте, artem2309, Вы писали:
A>>Подскажите в чем отличие primary key от unique?
vvu>Еще, Первичный служит для организации ссылочной целостности.
И unique тоже
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, vvu, Вы писали:
vvu>>Здравствуйте, artem2309, Вы писали:
A>>>Подскажите в чем отличие primary key от unique?
vvu>>Еще, Первичный служит для организации ссылочной целостности. vvu>>А Уникальный просто, чтобы значения поля (групп полей) не повторялись. V>Не совсем так. Unique тоже может служить для ссылочной целостности, например, через unique может быть создан альтернативный ключ.
Согласен Но я думаю или даже читал где-то (скорее всего читал, а теперь думаю), что лучше (предпочтительнее) использовать PK.
Кстати, про AK я вообще не очень понимаю, т.к. не приходилось сталкиваться. Я так думаю, что AK для ссылочной целостности, при наличии PK может понадобится использовать в какой-то ИСКЛЮЧИТЕЛЬНОЙ ситуации. А вот в какой? Я придумать не могу
Здравствуйте, Lloyd, Вы писали:
vvu>>Еще, Первичный служит для организации ссылочной целостности. L>И unique тоже
А когда (в каких случаях, задачах) это может понадобиться
ЗЫ: подробно свое неведение описал в ответе на сообщение vmpire.
Здравствуйте, vvu, Вы писали:
vvu>Здравствуйте, Lloyd, Вы писали:
vvu>>>Еще, Первичный служит для организации ссылочной целостности. L>>И unique тоже vvu>А когда (в каких случаях, задачах) это может понадобиться
Ни в каких. При создании внешнего ключа всегда лучше пользоваться
первичным ключом.
Здравствуйте, Flying Dutchman, Вы писали:
FD>Здравствуйте, vvu, Вы писали:
vvu>>Здравствуйте, Lloyd, Вы писали:
vvu>>>>Еще, Первичный служит для организации ссылочной целостности. L>>>И unique тоже vvu>>А когда (в каких случаях, задачах) это может понадобиться
FD>Ни в каких. При создании внешнего ключа всегда лучше пользоваться FD>первичным ключом.
Неправда твоя. А если у меня составной ключ и одно из полей допускает значения null — здесь только UK.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Здравствуйте, vvu, Вы писали:
vvu>>>Здравствуйте, Lloyd, Вы писали:
vvu>>>>>Еще, Первичный служит для организации ссылочной целостности. L>>>>И unique тоже vvu>>>А когда (в каких случаях, задачах) это может понадобиться
FD>>Ни в каких. При создании внешнего ключа всегда лучше пользоваться FD>>первичным ключом.
___>Неправда твоя. А если у меня составной ключ и одно из полей допускает значения null — здесь только UK.
Под словами "первичный ключ" я имею в виду первичный ключ с точки зрения реляционной теории.
То есть, если у тебя в таблице есть составной ключ и этот ключ единственный, то он является
первичным независимо от того, допускает ли его поле значение null или нет (хотя в первом случае
реализовать его можно только при помощи unique constraint).
Смысл моего предыдущего поста в том, что не стоит использовать для организации
сслылочной целостности альтернативный ключ.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Здравствуйте, vvu, Вы писали:
vvu>>>Здравствуйте, Lloyd, Вы писали:
vvu>>>>>Еще, Первичный служит для организации ссылочной целостности. L>>>>И unique тоже vvu>>>А когда (в каких случаях, задачах) это может понадобиться
FD>>Ни в каких. При создании внешнего ключа всегда лучше пользоваться FD>>первичным ключом.
___>Неправда твоя. А если у меня составной ключ и одно из полей допускает значения null — здесь только UK.
Здравствуйте, <Аноним>, Вы писали:
А>Отличие между ними заключается в том, что ограничение UNIQUE допускает ввод неопределенных значений и генерирует некластерный индекс, тогда как в PRIMARY KEY не допускается использование неопределенных значений и используется кластерный индекс (физическая сортировка данных в порядке индекса).
Кластерные индексы — это вообще в другую степь.
1. в конкретной СУБД может вообще не быть кластерных индексов
2. В том же SQL Server, где кластерные индексы есть, их можно назначить на совсем даже не Primary Key. На PK они просто ставятся "по умолчанию".
Но я думаю или даже читал где-то (скорее всего читал, а теперь думаю), что лучше (предпочтительнее) использовать PK.
