ima raznih principa, neki ce ti reci da uzmes document storage a ne
mysql, vrlo cest princip je da imas jedno string polje u koje ubacis te
reci kao stringove i imas full text index nad tim poljem i radis match()
.. imas varijantu da svaki put kad se dodaje novi tag dodajes ga u
tabelu tag_id, tag_name, pa onda uz dokument vezujes document_id, tag_id
... najbolji nacin tesko da postoji

Ne bi bilo lose da objasnis nesto vise o tagovima... sustina dobrog odgovora je :

- Koliko ima (razlicitih) tagova koji ce biti u upotrebi? Teoretski mnogo, ali prakticno, posebno ako imas auto-complete, ljudi vise vole da izaberu nego da kucaju do kraja... brzo se iskristalise par stotina popularnih, sve ostalo ode.
- Koliko tagova moze jedan dokument da ima? Takodje, koliko dokumenata ces imati u bazi, red velicine?

Meni mozda ima smisla neki EAV-like fazon sa 3-4 tabele, jedna ima opis dokumenta, druga tagove i jedna ili dve usmerene vezne. Opet, mnogo zavisi od brojeva....

U sustini, imas dokumenta, imas tagove i imas neku n-n relaciju izmedju njih, ja bi RDBMS modelirao na osnovu toga. E sad, prvo, zavisi sta je tebi efikasno, drugo zavisi kako se sistem koristi....

Biće tu dosta i dokumenata i artikala i partnera... pa mi je ideja bila da tagovima uvedem neku slobodniju vrstu kategorizacije. Dakle, nemam nikakve posebne zahteve, i dalje sam samo na nivou arhitekture. Prečešljao sam brojne forume i otprilike su slični odgovori. Ne postoji idealno rešenje za tagove. Zbog svoje slobodne prirode, teško ih je obuzdati relacionim modelima. Sve mi se čini da u mom slučaju trošak (kompleksnije implementacije, održavanja i performansi) prevazilazi dobiti pa ću verovatno odustati od istih. Preći ću na sistem dimenzija što mu dođe nešto kao višestruke kategorizacije. Češće se koristi u erp sistemima (što je nalik ovome što pravim), jes da ima nešto manju slobodu od tagova ali opet dovoljno dobro da ne mora da te boli glava ;)

pa vidi ne moras da izbegavas tagove, kako god ih napravis isplati se
... ja licno najcesce radi onu verziju sa tag_id, tag_name +
document_id, tag_id taelama ... imas jedan dodatni korak kada
insertujes/editujes dokument da proveris koji tagovi vec postoje a koji
su novi, nove insertujes (i pokupis id's) a za postojece pokupis id's in
onda tim id's popunis document_id, tag_id tabelu .. realno super
varijanta zato sto relativno jeftino dobijes auto expansion kada neko
kuca tagove .. (to sa fts resenjem ne ide tako brzo i tako lako, a sa
externim pretrazivacima tipa da uvodis sphinx, elastic, lucene/solr..  i
slicno je dodatni posao) ... radi to lepo, a def. nema potrebe da za
tako nesto uvodis json

Ne znam sta json radi u bazi uopste ;p

U praksi tag nije samo jedna reč nego uz tu reš obično ide i slug (string koji se korsiti u URL taga), pa ume dabude i veza ka tagu koji ima isto značenje (sinonim, ili je na drugom jeziku ili pismu), pa onda ide brojač poularnijih tagova itd... sve to miriše na tablarno organizovanje tagova kao složenih podataka.

Upravo to sam i ja mislio, to sam video vise puta u praksi, radi odlicno, testirano na bazama sa par desetina miliona redova. :)

Možda je već rešeno pa je odgovor zakasnio

Mislim da je wordpress to lepo rešio, uz tekst uneseš ključnu reč, proveri da li postoji, ako ne onda doda

recimo primer, pogledati sa desne strane Kategorija

p.s. ovo je samo primer koji je google našao, nemam nikakve veze s tim, da ne ispadne reklama