Составной альтернативный ключ в таблицах

Question

Предположим, что таблица имеет 4 столбца A, B, C и D. Только столбец определяет уникальность, поэтому это первичный ключ.B, C и D позволяют повторять записи, поэтому мы не можем воспринимать их как составной альтернативный ключ.Можно ли использовать один и тот же столбец в первичном ключе и альтернативном ключе, скажем, для создания альтернативного ключа в виде (A и B)?

Answer 1

Если я не понял вашу идею, для MS SQL это вполне возможно, посмотрите на этот тест:

CREATE TABLE Alternate (
    A int IDENTITY(1,1) NOT NULL,
    B int NULL,
    C int NULL,
    D int NULL,
 CONSTRAINT PK_Alternate PRIMARY KEY (A),
 CONSTRAINT AK_Alternate Unique (A,B)
)
GO

insert into Alternate (B) values(1)
insert into Alternate (B) values(1)
insert into Alternate (B) values(1)
insert into Alternate (B) values(null)
insert into Alternate (B) values(null)
insert into Alternate (B) values(null)

select A, B from Alternate

Результат будет следующим:

1 1

2 1

3 1

4 NULL

5 NULL

6 NULL

Answer 2

Формально:

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

Так что в вашем примере: {A, B} равно , а не ключ, поскольку он не минимален (вы можете убрать B и сохранить уникальность).

В то время как типичная СУБД будет , вы сможете создать уникальное ограничение, которое«содержит» ПЕРВИЧНЫЙ КЛЮЧ, это не очень хорошая идея - вы бы нарушили принцип проектирования базы данных, согласно которому «все должно зависеть от ключа, всего ключа и ничего, кроме ключа».

---

Кстатизачем тебе вообще такое делать?Вы просто пытаетесь избежать двух индексов (на {A} и {A, B}) по соображениям производительности?Если это так, имейте в виду, что «индекс» и «ключ» - это две разные концепции: первая связана с физикой / производительностью, а вторая - логично.Тот факт, что ключ часто поддерживается индексом (по соображениям производительности), не должен стирать это различие.

В зависимости от вашей СУБД, вы, вероятно, сможете создать INDEX для {A, B} иПЕРВИЧНЫЙ КЛЮЧ на A без необходимости складывать INDEX на {A}.