Du ønsker måske at tackle dette på følgende måde:
CREATE TABLE comments (
comment_id int,
body varchar(100),
PRIMARY KEY (comment_id)
);
CREATE TABLE users (
user_id int,
username varchar(20),
PRIMARY KEY (user_id)
);
CREATE TABLE comments_votes (
comment_id int,
user_id int,
vote_type int,
PRIMARY KEY (comment_id, user_id)
);
Den sammensatte primære nøgle
(comment_id, user_id)
på skæringstabellen
comments_votes
vil forhindre brugere i at stemme flere gange på de samme kommentarer.
Lad os indsætte nogle data i ovenstående skema:
INSERT INTO comments VALUES (1, 'first comment');
INSERT INTO comments VALUES (2, 'second comment');
INSERT INTO comments VALUES (3, 'third comment');
INSERT INTO users VALUES (1, 'user_a');
INSERT INTO users VALUES (2, 'user_b');
INSERT INTO users VALUES (3, 'user_c');
Lad os nu tilføje nogle stemmer til bruger 1:
INSERT INTO comments_votes VALUES (1, 1, 1);
INSERT INTO comments_votes VALUES (2, 1, 1);
Ovenstående betyder, at bruger 1 afgav en stemme af type 1 på kommentar 1 og 2.
Hvis den samme bruger forsøger at stemme igen på en af disse kommentarer, vil databasen afvise den:
INSERT INTO comments_votes VALUES (1, 1, 1);
ERROR 1062 (23000): Duplicate entry '1-1' for key 'PRIMARY'
Hvis du vil bruge InnoDB
lagermotor, vil det også være klogt at bruge fremmednøgle
begrænsninger på comment_id
og user_id
felter i skæringstabellen. Bemærk dog, at MyISAM
, standardlagermaskinen i MySQL, håndhæver ikke begrænsninger for fremmednøgle:
CREATE TABLE comments (
comment_id int,
body varchar(100),
PRIMARY KEY (comment_id)
) ENGINE=INNODB;
CREATE TABLE users (
user_id int,
username varchar(20),
PRIMARY KEY (user_id)
) ENGINE=INNODB;
CREATE TABLE comments_votes (
comment_id int,
user_id int,
vote_type int,
PRIMARY KEY (comment_id, user_id),
FOREIGN KEY (comment_id) REFERENCES comments (comment_id),
FOREIGN KEY (user_id) REFERENCES users (user_id)
) ENGINE=INNODB;
Disse fremmednøgler garanterer, at en række i comments_votes
vil aldrig have et comment_id
eller user_id
værdi, der ikke findes i comments
og users
henholdsvis tabeller. Fremmednøgler er ikke påkrævet for at have en fungerende relationsdatabase, men de er absolut nødvendige for at undgå ødelagte relationer og forældreløse rækker (f.eks. henvisningsintegritet
).
Faktisk er referentiel integritet noget, der ville have været meget vanskeligt at håndhæve, hvis du skulle gemme serialiserede arrays i et enkelt databasefelt.