Wiele, ale wzajemnie wykluczających się kluczy obcych — czy to jest droga?

Jeśli przyjrzymy się temu modelowi, zobaczymy:

1. Użytkownik jest powiązany z dokładnie jedną witryną
   • Firma jest powiązana z dokładnie jedną witryną
   • Witryna jest powiązana z dokładnie jednym użytkownikiem lub firmą

Trzecia relacja sugeruje istnienie encji „użytkownika lub firmy”, której PRIMARY KEY powinny być gdzieś przechowywane.

Aby go przechowywać, musisz utworzyć tabelę, która będzie przechowywać PRIMARY KEY website owner podmiot. Ta tabela może również przechowywać atrybuty wspólne dla użytkownika i witryny.

Ponieważ jest to relacja jeden do jednego, atrybuty witryny mogą być również przechowywane w tej tabeli.

Atrybuty, które nie są współdzielone przez użytkowników i firmy, powinny być przechowywane w osobnej tabeli.

Aby wymusić prawidłowe relacje, musisz utworzyć PRIMARY KEY website złożony z owner type jako jego część i wymuś poprawny typ w tabelach podrzędnych za pomocą CHECK ograniczenie:

CREATE TABLE website_owner (
    type INT NOT NULL,
    id INT NOT NULL,
    website_attributes,
    common_attributes,
    CHECK (type IN (1, 2)) -- 1 for user, 2 for company
    PRIMARY KEY (type, id)
)

CREATE TABLE user (
    type INT NOT NULL,
    id INT NOT NULL PRIMARY KEY,
    user_attributes,
    CHECK (type = 1),
    FOREIGN KEY (type, id) REFERENCES website_owner
)

CREATE TABLE company (
    type INT NOT NULL,
    id INT NOT NULL PRIMARY KEY,
    company_attributes,
    CHECK (type = 2),
    FOREIGN KEY (type, id) REFERENCES website_owner
)