Først og fremmest er "toxi" ikke et standardbegreb. Definer altid dine vilkår! Eller i det mindste giv relevante links.
Og nu til selve spørgsmålet...
Nej, du har 3 borde.
Du er stort set på rette vej, med den undtagelse at du kan bruge den sæt-baserede karakter af SQL til at "flette" mange af disse trin. Tag f.eks. et element 1 med tags:'tag1', 'tag2' og 'tag3' kan gøres på denne måde...
INSERT IGNORE INTO tagmap (item_id, tag_id)
SELECT 1, tag_id FROM tags WHERE tag_text IN ('tag1', 'tag2', 'tag3');
IGNORE tillader dette at lykkes, selvom elementet allerede er forbundet til nogle af disse tags.
Dette forudsætter, at alle nødvendige tags allerede er i tags . Forudsat tag.tag_id er automatisk stigning, kan du gøre sådan noget for at sikre, at de er:
INSERT IGNORE INTO tags (tag_text) VALUES ('tag1'), ('tag2'), ('tag3');
Der er ingen magi. Hvis "emne er forbundet til et bestemt tag" er en viden, du vil optage, så vil den have at have en form for fysisk repræsentation i databasen.
Du mener at gentagge elementer (ikke at ændre tags i sig selv)?
For at fjerne alle tags, der ikke er på listen, skal du gøre noget som dette:
DELETE FROM tagmap
WHERE
item_id = 1
AND tag_id NOT IN (
SELECT tag_id FROM tags
WHERE tag_text IN ('tag1', 'tag3')
);
Dette vil frakoble elementet fra alle tags undtagen 'tag1' og 'tag3'. Udfør INSERT ovenfor og denne DELETE en efter en for at "dække" både tilføjelse og fjernelse af tags.
Du kan lege med alt dette i SQL Fiddle .
Korrekt. Et underordnet endepunkt for en FK vil ikke udløse en henvisningshandling (såsom PÅ SLET KASCADE), kun forælder vil.
BTW, du bruger dette skema, fordi du vil have yderligere felter i tags (ved siden af tag_text ), ret? Hvis du gør det, er det ønsket adfærd ikke at miste disse yderligere data, bare fordi alle forbindelser er væk.
Men hvis du bare ville have tag_text , ville du bruge et enklere skema, hvor sletning af alle forbindelser ville være det samme som at slette selve tagget:
Dette ville ikke blot forenkle SQL, det ville også give bedre clustering .
Ved første øjekast kan "toxi" se ud som om det sparer plads, men det er måske faktisk ikke tilfældet i praksis, da det kræver yderligere tabeller og indekser (og tags har en tendens til at være korte).
Mål før du beslutter dig for at gøre sådan noget. My SQL Fiddle nævnt ovenfor bruger en meget bevidst rækkefølge af felter i tagmap PK, så data er grupperet på en måde, der er meget venlig over for denne form for optælling (husk:InnoDB-tabeller er grupperet
). Du skal have en virkelig stor mængde varer (eller kræve usædvanlig høj ydeevne), før dette bliver et problem.
Under alle omstændigheder mål på realistiske mængder af data!