[php][mysql] Aktualizacja list relacyjnych, Problem koncepcyjny Opcje

[markonix]

Może na prostym, fikcyjnym przykładzie:

Dodajemy wpis w CMS.
Jednym z atrybutów wpisu są TAGI (0..n).
Tagi dodawane są dynamicznie przez pola input (JS).
Dodajemy wpis i kilka tagów my przypisanych.
Tutaj nie ma większego problemu - korzystamy z INSERT w pętli, PS bądź insert batch (akurat teraz pracuje na CodeIgniter).
Na tagi mamy oddzielną tabelę w bazie o strukturze:
[ id ] [ art_id ] [ name ]

I teraz chciałbym edytować listę. W jaki sposób?

1) update na podstawie [id], w porządku ale co zrobić gdy ktoś doda nowy tag? Wtedy też trzeba wykrywać nowo dodane wartości?
2) co zrobić w przypadku usunięcia? znów kolejne zapytania?

Najprostsze rozwiązanie jakie mi przychodzi do głowy to:
- usuwamy wszystko co ma art_id = X
- dodajemy na nowo tagi
Te rozwiązanie jest jednak niewygodne ze względu na szybkie narastanie wartości ID -> np. mając 20 tagów każda edycja (bez względu na to ile się zmieniło) zwiększa najwyższe id o 20. Poza tym te operacje wydają mi się mało wydajne - nawet gdy nie zmieni tagów to wykonają się dwa spore zapytania.

Praktycznie ten problem koncepcyjny wraca do mnie jak bumerang. Za każdym razem mam jakiś pomysł ale żaden mnie nie satysfakcjonuje.

Jakieś sugestie?

[markonix]

Tzn uproszczając chodzi Ci o:

ARTS: id, title...
Tags: id_art, name

Czyli pominięcie ID w tabeli tagu?

Takie rozwiązanie raz zastosowałem i działa w porządku choć nadal nie rozwiązuje kwestii optymalności - duży delete, duży insert.
Te rozwiązanie także ma minus że TAGi nie mają swoich ID co może potem narobić kłopotów.
Twoja struktura problem z ID niweluje ale dodaje tu już trzecią tabelę - kolejne JOINy, troszkę taki przerost formy. Poza tym pierwszy insert nie da się załatwić jednym zapytaniem bo musisz najpierw dodawać wpis do tabeli TAG aby otrzymać id, potrzebne w tabeli ART_TAG.

Mam jeszcze inny pomysł (na dwóch tabelach):
podwójny indeks na id i art_id UNIQ. Wykonanie INSERT / UPDATE ON DUPLICATE na każdym rekordzie.
Potem wszystkie ID wykorzystane lecą do DELETE NOT IN.
Też troszkę zapytań ale na dwóch tabelach i delete, który wywali mniej rekordów.

Jeszcze 3 brzydka ale optymalna opcja.
Na jednej tabeli i dodatkowa kolumna "tags" z tablicą (serializacja).

Ten post edytował markonix 19.08.2013, 13:21:42