Добавьте ДРУГОЙ первичный ключ к таблице, которая УНИКАЛЬНА - PullRequest
Новая
       10

Добавьте ДРУГОЙ первичный ключ к таблице, которая УНИКАЛЬНА

1 голос
/ 09 марта 2011

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

  1. Идентификатор учетной записи (личность)
  2. EmailID
  3. Поле данных

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

PRIMARY KEY (AccountID, EmailID)

Я думал, что это сделает мой emailid уникальным, но потом, после того, как я попытался вставить другую строку с тем же emailid, он прошел. Поэтому я подумал, что что-то упустил.

Теперь на мой вопрос:

  1. ЕСЛИ мне пришлось использовать alter, как мне изменить ограничение таблицы / PK, чтобы изменить поле EmailID и сделать его уникальным?
  2. Если я решил отбросить таблицу и создал новую, как мне сделать эти два первичных ключа уникальными?

Ответы [ 4 ]

6 голосов
/ 09 марта 2011

Вы можете изменить таблицу и добавить новый УНИКАЛЬНОЕ ОГРАНИЧЕНИЕ в столбец EmailID. 

-- This will create a constraint which enforces that the field EmailID
-- have unique values
ALTER TABLE Your_Table_Name
ADD CONSTRAINT unique_constraint_name UNIQUE (EmailID)

Стоит отметить, однако, что изменение таблицы для добавления этого нового уникального ограничения не означает, что вы должны отбросить другое ограничение PRIMARY KEY, которое вы добавили для пары (AccountID, EmailID). Это, конечно, если ваша бизнес-логика не диктует это.

Когда вы делаете группировку (AcountID, EmailID) PRIMARY KEY, это указывает, что и AcountID, и EmailID участвуют в уникальной идентификации каждой отдельной записи в этой таблице. Таким образом, это означает, что в таблице могут быть следующие записи: 

 AccountID  |  EmailID                  |  Other Fields
----------------------------------------------------------
 100        |  user@company.com         |     ....
 101        |  user2@othermail.com      |     ....
 100        |  user_alternate@mail.com  |     ....

В предыдущем примере возможно иметь две записи с одним и тем же AccountID, и это действительно, потому что PRIMARY KEY указывает, что только пара (AccountID, EmailID) должна быть уникальной, какой она является. В нем не указывается, что AccountID является уникальным независимо.

В заключение вы, вероятно, захотите добавить еще одно уникальное ограничение на AccountID. Или просто сделайте только AccountID ПЕРВИЧНЫМ КЛЮЧОМ, а затем добавьте УНИКАЛЬНОЕ ограничение на EmailID.

2 голосов
/ 09 марта 2011

Если оба ключа AccountID и EmailID являются кандидатами, то только 1003 * может быть только один, для другого потребуется уникальное ограничение.

От POV SQL Server не имеет значения, какой из них вы выбрали в качестве PK. Внешний ключ может ссылаться либо на PK, либо на уникальное ограничение, но, учитывая, что PK является кластеризованным индексом по умолчанию, вероятно, имеет смысл выбрать AccountID, так как это предположительно уже и более стабильно.

0 голосов
/ 09 марта 2011

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

CREATE TABLE dbo.AccountEmails
(
    AccountID int not null identity(1,1),
    EmailID int not null,
    Data varchar(max) null,
    constraint PK_AccountEmails PRIMARY KEY //this is a unique single column primary key
    (
        AccountID
    ),
    constraint FK_AccountEmails_EmailID FOREIGN KEY dbo.Email(EmailID) ON //this makes sure EmailID exists in the Email table
    (
        EmailID
    ),
    constraint UQ_AccountEmails_EmailID UNIQUE //unique single column unique constraint
    (
        EmailID
    ),
    constraint UQ_AccountEmails_AccountID_EmailID UNIQUE //the combination of AccountID and EmailID is also unique
    (
        AccountID,
        EmailID
    )
)

Учитывая тот факт, что AccountID и EmailID по отдельности являются уникальными, я не уверен, что UQ_AccountEmails_AccountID_EmailID действительно необходим.

0 голосов
/ 09 марта 2011

Звучит как неправильный первичный ключ. Скорее всего, emailID предназначен для использования в качестве естественного ключа, но по какой-то причине (может быть, стандартом разработки в вашей организации?) Вы хотите использовать суррогатный идентификатор, идентификатор учетной записи, но вы по-прежнему хотите, чтобы оба идентификатора электронной почты и суррогатный идентификатор были уникальными и иметь отношения один к одному. Если это так, то вашим первичным ключом должен быть AccountID, и вы должны наложить уникальное ограничение на EmailID.

...