Flere, men gensidigt ekskluderende fremmednøgler - er det vejen at gå?

Hvis vi ser nærmere på modellen her, vil vi se følgende:

1. En bruger er relateret til præcis ét websted
   • En virksomhed er relateret til præcis ét websted
   • Et websted er relateret til præcis én bruger eller virksomhed

Den tredje relation indebærer eksistensen af ​​en "bruger eller virksomhed"-entitet, hvis PRIMARY KEY skal opbevares et sted.

For at gemme det skal du oprette en tabel, der vil gemme en PRIMARY KEY af en website owner enhed. Denne tabel kan også gemme attributter, der er fælles for en bruger og et websted.

Da det er en en-til-en-relation, kan webstedsattributter også gemmes i denne tabel.

De attributter, der ikke deles af brugere og virksomheder, skal gemmes i den separate tabel.

For at fremtvinge de korrekte relationer skal du lave den PRIMARY KEY af website sammensat med owner type som en del af det, og fremtving den korrekte type i de underordnede tabeller med en CHECK begrænsning:

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
)