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.