Chiave alternativa composita nelle tabelle

Question

Supponiamo che una tabella abbia 4 colonne A, B, C e D. Solo una colonna definisce unicità ecco perché è una chiave primaria. B, C e D consentono alle voci di ripetere, è per questo che non possiamo prenderle come una chiave alternativa composita. È possibile utilizzare la stessa colonna nella chiave primaria e sulla chiave alternativa, per esempio, per creare una chiave alternativa come (a e b)?

Answer 1

A meno che non ho avuto la tua idea, per MS SQL è del tutto possibile, guarda questo test:

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

Il risultato è il seguente:

1 1

2 1

3 1

4 null

5 null

6 null

Answer 2

Formalmente:

• Un "superkey" è un insieme di attributi che, presi insieme, sono in grado di identificare in modo univoco le file.
• Una "chiave" è un minimo Superkey - cioè se se togli qualche attributo da esso, non sarà più unico.

Quindi nel tuo esempio: {a, b} è non una chiave perché lo è non minimo (Puoi togliere B e avere ancora unicità).

Mentre un tipico DBMS volere Lascia che tu sia un vincolo unico che "contiene" la chiave primaria, questa non è una buona idea: violare un principio di progettazione del database secondo cui "tutto dovrebbe dipendere da una chiave, intera e nient'altro che dalla chiave".

---

A proposito, perché dovresti voler fare una cosa del genere? Stai solo cercando di evitare di avere 2 indici (su {a} e su {a, b}) per motivi di prestazione? In tal caso, tieni presente che "indice" e "chiave" sono due concetti separati: il primo è legato fisico/per le prestazioni mentre il secondo è logico. Il fatto che una chiave sia spesso supportata da un indice (per motivi di performance) non dovrebbe offuscare questa distinzione.

A seconda del tuo DBMS, sarai probabilmente in grado di mettere un indice su {a, b} e la chiave primaria su a senza dover cavare l'indice su {a}.