[PHP/MYSQL] JSON als koppeltabel alternatief

[HollowGamer]

Voorbeeld tabellen:
Boeken
| col | type | val |
|-------- |-------------- |------------------ |
| id | autoincr. | 1 |
| title | varchar(255) | Boek Titel |
| custom | text | {"tags":[1,3,5]} |

Tags
| id | title |
|---- |-------------- |
| 1 | Horror |
| 2 | Geschiedenis |
| 3 | Drama |
| 4 | Top-seller |
| 5 | Waargebeurd |

De bedoeling is dat je per boek, meerdere tags kan meegeven.
Het is echter dus ook de bedoeling dat je kan filteren op tags.

Zelf heb ik een PHP-(zoekmachine)code geschreven die eerst alle records ophaalt, vervolgens de tags met json_decode in een array plaatst, en vervolgens met in_array checkt of deze ID's matchen (dus als iemand zoekt met de tag 'Drama' => 1, maar ook meerdere tags zijn natuurlijk mogelijk.).
Het werkt allemaal, maar het is natuurlijk niet de manier hoe het zal moeten.

Voorbeelden hoe het zoeken werkt/zou moeten werken:
#Horror #Top-seller
#Horror title-boek
title-boek
..

Ik heb gekeken naar NoSQL alternatieven, maar ik ben daar niet zo mee bekend, en de vraag is dus of dit beter met een noSQL oplossing (MongoDB) zou moeten of toch gewoon kan met MySQL?
Sinds versie 7 zijn er namelijk nieuwe JSON functies toegevoegd, maar volgens mij zit er de mogelijkheid die ik graag zou hebben er niet bij?

MongoDB lijkt mij interessant, mede doordat deze standaard werkt in het JSON-formaat, echter ben ik daar dus niet zo mee bekend en vraag ik mij af of dit de goede weg is.

Het gaat mij uiteindelijk wel lukken, maar ik heb het gevoel niet correct bezig te zijn ..
Zijn koppeltabellen nou eenmaal nodig?

Hopelijk kunnen jullie mij verder helpen,

Alvast bedankt.

[RM-rf]

volgens mij kun je dit ook al direkt in mysql doen als je die hele extra json-encoding dropt en gewoon een comma-sparated list opslaat en deze dan doorzoekt met FIND_IN_SET:

http://dev.mysql.com/doc/...html#function_find-in-set

edit: (hmm, dan moet je wel een SET filetype gebruiken en die heeft maximaal 64 waardes, toch moet het zeker optimaler kunnen door direkt mysql te gebruiken )

[ Voor 24% gewijzigd door RM-rf op 10-05-2016 13:18 ]

[NMe]

Waarom wil je nou van een goed datamodel af stappen om over te gaan op een abominabel en niet-indexeerbaar alternatief? De query om op één of meerdere tags te zoeken is toch zo complex niet?

SQL:

SELECT boek.*, COUNT(tags.id) AS nr_tags
FROM boek JOIN boektag ON boek.id = boektag.boekid
     JOIN tag ON boektag.tagid = tag.id
WHERE tag.id IN (<id's van alle tags die je zoekt>)
GROUP BY boek.id
HAVING COUNT(tags.id) = <aantal tags waar je op zocht>

Op die manier vind je alleen alle boeken die elk van die tags heeft zonder naar lelijke database-in-een-databaseoplossingen te hoeven grijpen. En als je "any" in plaats van "all" tags wil vinden hoef je alleen maar de HAVING weg te halen, de inner joins doen de rest.

edit:

Voor de puristen: ja, die GROUP BY heb ik "verkeerd" uitgeschreven, maar dit is precies de usecase waarin het gebruik op deze manier valide en voorspelbaar is.

[ Voor 19% gewijzigd door NMe op 10-05-2016 13:24 ]

[HollowGamer]

RM-rf schreef op dinsdag 10 mei 2016 @ 13:12:
volgens mij kun je dit ook al direkt in mysql doen als je die hele extra json-encoding dropt en gewoon een comma-sparated list opslaat en deze dan doorzoekt met FIND_IN_SET:

http://dev.mysql.com/doc/...html#function_find-in-set

Deze oplossing lijkt mij het minst complex.

NMe schreef op dinsdag 10 mei 2016 @ 13:21:
Waarom wil je nou van een goed datamodel af stappen om over te gaan op een abominabel en niet-indexeerbaar alternatief? De query om op één of meerdere tags te zoeken is toch zo complex niet?

SQL:

SELECT boek.*, COUNT(tags.id) AS nr_tags
FROM boek JOIN boektag ON boek.id = boektag.boekid
     JOIN tag ON boektag.tagid = tag.id
WHERE tag.id IN (<id's van alle tags die je zoekt>)
GROUP BY boek.id
HAVING COUNT(tags.id) = <aantal tags waar je op zocht>

Op die manier vind je alleen alle boeken die elk van die tags heeft zonder naar lelijke database-in-een-databaseoplossingen te hoeven grijpen.

edit:

Voor de puristen: ja, die GROUP BY heb ik "verkeerd" uitgeschreven, maar dit is precies de usecase waarin het gebruik op deze manier valide en voorspelbaar is.

Thanks! Ga de query straks eens uit proberen, deze oplossing zou ik ook mooi kunnen gebruiken met Slim-PDO.

Kom ik bij deze niet in de problemen? (JOIN tag ON boektag.tagid = tag.id)
Aangezien er meerdere ID's mogelijk zijn.

Wat bedoel je precies met GROUP BY "verkeerd" uitgeschreven? Ja, zo'n prutser hier.

[ Voor 3% gewijzigd door HollowGamer op 10-05-2016 13:28 ]

[NMe]

Die group by is niet correct in andere smaakjes van SQL dan MySQL, zie Programming FAQ - SQL: Hoe werkt dat GROUP BY nu eigenlijk? Maar zoals ik al zei: MySQL staat dit bewust toe juist voor dit soort usecases waar het voluit herhalen van de hele select niet veel toevoegt.

[HollowGamer]

NMe schreef op dinsdag 10 mei 2016 @ 13:21:
Waarom wil je nou van een goed datamodel af stappen om over te gaan op een abominabel en niet-indexeerbaar alternatief? De query om op één of meerdere tags te zoeken is toch zo complex niet?

SQL:

SELECT boek.*, COUNT(tags.id) AS nr_tags
FROM boek JOIN boektag ON boek.id = boektag.boekid
     JOIN tag ON boektag.tagid = tag.id
WHERE tag.id IN (<id's van alle tags die je zoekt>)
GROUP BY boek.id
HAVING COUNT(tags.id) = <aantal tags waar je op zocht>

Op die manier vind je alleen alle boeken die elk van die tags heeft zonder naar lelijke database-in-een-databaseoplossingen te hoeven grijpen. En als je "any" in plaats van "all" tags wil vinden hoef je alleen maar de HAVING weg te halen, de inner joins doen de rest.

edit:

Voor de puristen: ja, die GROUP BY heb ik "verkeerd" uitgeschreven, maar dit is precies de usecase waarin het gebruik op deze manier valide en voorspelbaar is.

Inmiddels geprobeerd, en het werkt prima.
Is het alleen ook mogelijk de tag tabel mee te geven?
In de tag tabel heb ik bijvoorbeeld de titel (nice name) staan.

.. Het is inmiddels gelukt:

SQL:

SELECT movie.*, GROUP_CONCAT('{id: "', tag.tag_id, '", title: "', tag.tag_title,'"}') tags
FROM movie
JOIN movie_tag ON movie.movie_id = movie_tag.movie_id
JOIN tag ON movie_tag.tag_id = tag.tag_id
WHERE tag.tag_id IN (1,3,5)
GROUP BY movie.movie_id, movie.movie_title

Resultaat:

SQL:

movie_id    movie_title movie_description   movie_status    movie_posted    movie_modified  tags
1   Title 1     0   2015-06-13 17:39:43 0000-00-00 00:00:00 {id: "1", title: "Tag 1"},{id: "3", title: "Tag 3"},{id: "5", title: "Tag 5"}
3   Title 2     0   2015-06-13 17:39:43 0000-00-00 00:00:00 {id: "5", title: "Tag 5"},{id: "1", title: "Tag 1"}

Nu wordt het weergeven in JSON, ben alleen aan het zoeken naar een korte versie/functie, maar die zitten volgensmij nog niet in MariaDB. Mocht iemand de tip hebben om het korte te krijgen, graag.

Many thanks

[ Voor 44% gewijzigd door HollowGamer op 10-05-2016 21:59 ]

[Cartman!]

Het weergeven van data moet je doen in je presentatielaag, niet in je query en dan heb je dat probleem ook niet.

[HollowGamer]

Cartman! schreef op zaterdag 14 mei 2016 @ 21:03:
Het weergeven van data moet je doen in je presentatielaag, niet in je query en dan heb je dat probleem ook niet.

Ja en nee: bij deze oplossing wilde ik namelijk de data als JSON ophalen, zodat mijn presentatielaag dit eenvoudig kon parsen/verwerken.Het moet namelijk voor de presentatielaag (In dit geval Twig) wel mogelijk zijn deze te verwerken.

Ik ben van mening dat complexere relaties/berekenen gemaakt kunnen worden via de backend en vervolgens doorgeven worden als aan te roepen variable voor de view. Dingen als for, vertalingen, etc. is prima, maar liefst geen relaties leggen, sommen uitvoeren, etc.

Begrijp je comment niet helemaal, maar is dit zo hoe je het had bedoeld?

Verder heb ik het probleem anders opgelost; ben overgestapt op FULLTEXT(), waardoor je nu ook kan zoeken op tags en deze weer scores meekrijgen. Very nice!
Hierdoor moet ik wel alle tags in een column zetten van een record, maar dat is opzicht niet zo'n issue.
Relaties leg ik dus niet meer (in de vorm van koppeltabel), maar met FULLTEKST() los ik deze problemen (bij het zoeken naar content) eenvoudig en snel op.

[ Voor 13% gewijzigd door HollowGamer op 15-05-2016 21:39 ]

[Cartman!]

HollowGamer schreef op zondag 15 mei 2016 @ 21:36:
[...]

Ja en nee: bij deze oplossing wilde ik namelijk de data als JSON ophalen, zodat mijn presentatielaag dit eenvoudig kon parsen/verwerken.

Die dingen horen toch echt los van elkaar te staan. Stel iemand komt bij je met "en nu wil ik het als xml" dan ben je de zak want je hebt het alleen als json? Ga je dan een 2e query maken die alles als xml eruit gaat trekken?

Het moet namelijk voor de presentatielaag (In dit geval Twig) wel mogelijk zijn deze te verwerken.

Tussen je Model en je View kun/hoor je nog een laagje te stoppen die dat voor je kan doen.

Ik ben van mening dat complexere relaties/berekenen gemaakt kunnen worden via de backend en vervolgens doorgeven worden als aan te roepen variable voor de view. Dingen als for, vertalingen, etc. is prima, maar liefst geen relaties leggen, sommen uitvoeren, etc.

Beetje een wazige zin... ieder onderdeel van je applicatie heeft z'n verantwoordelijkheden en waarden omzetten naar json hoort simpelweg niet thuis in een query.

Begrijp je comment niet helemaal, maar is dit zo hoe je het had bedoeld?

Verder heb ik het probleem anders opgelost; ben overgestapt op FULLTEXT(), waardoor je nu ook kan zoeken op tags en deze weer scores meekrijgen. Very nice!

Tags is iets anders dan full text search en ik vind het twee wezenlijk andere dingen qua zoeken dus nu misbruik je eigenlijk je Fulltext search er een beetje voor. Wat nu als je een tag zou willen wijzigen? Alle records updaten?

Hierdoor moet ik wel alle tags in een column zetten van een record, maar dat is opzicht niet zo'n issue.
Relaties leg ik dus niet meer (in de vorm van koppeltabel), maar met FULLTEKST() los ik deze problemen (bij het zoeken naar content) eenvoudig en snel op.

En dat is dus juist een groot nadeel wat je voor jezelf hebt gecreerd

[HollowGamer]

Cartman! schreef op zondag 15 mei 2016 @ 21:50:
Die dingen horen toch echt los van elkaar te staan. Stel iemand komt bij je met "en nu wil ik het als xml" dan ben je de zak want je hebt het alleen als json? Ga je dan een 2e query maken die alles als xml eruit gaat trekken?

Nee, dan schrijf je een functie die de JSON data omzet naar XML.
JSON kan je heel eenvoudig encoden/decoden, dus daarin zie ik het probleem niet.
Dat ik toevallig een stukje JSON gebruik in een query, betekend niet dat alles in mijn applicatie dan maar JSON is.

Tussen je Model en je View kun/hoor je nog een laagje te stoppen die dat voor je kan doen.

Beetje een wazige zin... ieder onderdeel van je applicatie heeft z'n verantwoordelijkheden en waarden omzetten naar json hoort simpelweg niet thuis in een query.

Dat ligt er maar net aan wat je precies voor ogen hebt.

Dat stukje zette ik om naar JSON, zodat ik deze eenvoudig kan gebruiken waar/hoe ik dat wil.
Zo kan ik die JSON prima omgooien naar een array. Waarom JSON? Omdat ik binnen SQL niet gebruik kan maken van array's.

Ik had ook altijd het idee dat je met SQL simpelweg alleen kan querien, maar sinds ik ook met andere SQL talen iets meer ervaring hebt, weet ik dat je ook prima al zaken in SQL kunt oplossen.. wat dus weer zich vertaald in performance winst.

Tags is iets anders dan full text search en ik vind het twee wezenlijk andere dingen qua zoeken dus nu misbruik je eigenlijk je Fulltext search er een beetje voor. Wat nu als je een tag zou willen wijzigen? Alle records updaten?

En dat is dus juist een groot nadeel wat je voor jezelf hebt gecreerd

Dat ben ik met je eens, en daar raak je ook een punt.
Nergens wordt gecontroleerd of de tag wel voorkomt/mag voorkomen (behalve bij toevoegen/editen).

Echter is deze applicatie niet zo heel groot (max. 2000 records), waardoor je heel eenvoudig kan zoeken en replacen (de column wordt namelijk indexeert).

Design is nooit perfect, maar je hebt inderdaad gelijk dat er altijd ruimte is voor verbetering.

[ Voor 6% gewijzigd door HollowGamer op 15-05-2016 22:12 ]

[Cartman!]

HollowGamer schreef op zondag 15 mei 2016 @ 22:08:
Nee, dan schrijf je een functie die de JSON data omzet naar XML.

JSON kan je heel eenvoudig encoden/decoden, dus daarin zie ik het probleem niet.
Dat ik toevallig een stukje JSON gebruik in een query, betekend niet dat alles in mijn applicatie dan maar JSON is.

Je kan nog veel makkelijker niet heen en weer encoden en het maar 1 keer doen.

Dat ligt er maar net aan wat je precies voor ogen hebt.

Dat stukje zette ik om naar JSON, zodat ik deze eenvoudig kan gebruiken waar/hoe ik dat wil.
Zo kan ik die JSON prima omgooien naar een array. Waarom JSON? Omdat ik binnen SQL niet gebruik kan maken van array's.

Omdat je ook helemaal geen array nodig hebt, dat denk je alleen.

Ik had ook altijd het idee dat je met SQL simpelweg alleen kan querien, maar sinds ik ook met andere SQL talen iets meer ervaring hebt, weet ik dat je ook prima al zaken in SQL kunt oplossen.. wat dus weer zich vertaald in performance winst.

Als je van dit soort dingen performancewinst wil hebben dan gaat t volgens mij niet helemaal lekker. Verder dat het betekent dat je met wat functies JSON uit een query kan halen betekent niet dat t moet. Je had er ook meteen html van kunnen maken, het door een domparser kunnen halen en daarna weer encoden naar json. Het kan maar het is een stompzinnig idee.

Dat ben ik met je eens, en daar raak je ook een punt.
Nergens wordt gecontroleerd of de tag wel voorkomt/mag voorkomen (behalve bij toevoegen/editen).

Echter is deze applicatie niet zo heel groot (max. 2000 records), waardoor je heel eenvoudig kan zoeken en replacen (de column wordt namelijk indexeert).

Design is nooit perfect, maar je hebt inderdaad gelijk dat er altijd ruimte is voor verbetering.

Stop dan met eigenwijs doen en volg de adviezen hier op en leer jezelf geen bad practices aan

[HollowGamer]

Weet niet zeker of je het als troll bedoeld, of echt serieus.

Cartman! schreef op maandag 16 mei 2016 @ 11:34:
Je kan nog veel makkelijker niet heen en weer encoden en het maar 1 keer doen.
Omdat je ook helemaal geen array nodig hebt, dat denk je alleen.

Ik heb een array nodig, die ik wil gebruiken in mijn view/presentatie laag.

Als je van dit soort dingen performancewinst wil hebben dan gaat t volgens mij niet helemaal lekker. Verder dat het betekent dat je met wat functies JSON uit een query kan halen betekent niet dat t moet. Je had er ook meteen html van kunnen maken, het door een domparser kunnen halen en daarna weer encoden naar json. Het kan maar het is een stompzinnig idee.

Stop dan met eigenwijs doen en volg de adviezen hier op en leer jezelf geen bad practices aan

Zou je mij dan graag willen laten zien hoe jij het oplost, tot nu toe roeptoeter je alleen maar wat, maar een echte oplossing heb ik nog niet gezien.

[Cartman!]

HollowGamer schreef op maandag 16 mei 2016 @ 16:46:
Ik heb een array nodig, die ik wil gebruiken in mijn view/presentatie laag.

Dat legt niet uit waarom je dat in je query al wil doen. Je kunt vanuit je controller een repository aanroepen, daar voer je een query uit en zet je t om naar hoe je wilt hebben (bijv een array) en vanuit daar gooi je t naar je presentatielaag (wat zelfs simpelweg json_encode zou kunnen zijn).

Zou je mij dan graag willen laten zien hoe jij het oplost, tot nu toe roeptoeter je alleen maar wat, maar een echte oplossing heb ik nog niet gezien.

De oplossing is allang gegeven door NMe, het is mij een raadsel waarom dat het geaccepteerde antwoord is maar er uiteindelijk niets mee doet.

Als je denkt dat iemand die zo uitgebreid op je reacties in gaat "roeptoetert" dan gaat er volgens mij meer mis, volgens mij probeer ik je behoorlijk te helpen door je te laten inzien dat queries die json teruggeven niet de oplossing zijn.

[ Voor 13% gewijzigd door Cartman! op 16-05-2016 16:55 ]

[HollowGamer]

Cartman! schreef op maandag 16 mei 2016 @ 16:53:
[...]

Dat legt niet uit waarom je dat in je query al wil doen. Je kunt vanuit je controller een repository aanroepen, daar voer je een query uit en zet je t om naar hoe je wilt hebben (bijv een array) en vanuit daar gooi je t naar je presentatielaag (wat zelfs simpelweg json_encode zou kunnen zijn).

[...]

De oplossing is allang gegeven door NMe, het is mij een raadsel waarom dat het geaccepteerde antwoord is maar er uiteindelijk niets mee doet.

Als je denkt dat iemand die zo uitgebreid op je reacties in gaat "roeptoetert" dan gaat er volgens mij meer mis, volgens mij probeer ik je behoorlijk te helpen door je te laten inzien dat queries die json teruggeven niet de oplossing zijn.

Heb jou reactie nogmaals rustig gisteren op het gemak doorgelezen.
Verder waardeer ik je input en heb je zeker gelijk, echter verschillen we over een aantal dingen van mening.
Misschien dat de volgende uitleg iets meer input geeft:

De oplossing heb ik niet gekozen, omdat ik een alternatief heb gevonden dat beter mijn doel pas, namelijk FULLTEXT().

De geschreven applicatie (in SlimPHP met MVC) is eigenlijk een soort van Netflix kloon, alleen nu puur voor mijn eigen films/serie collectie, waarbij ik vooral werk op basis van 'tags' i.p.v. categoriseren.

Neem deze zoekterm: Car #action #comedy

Zoals je kunt zien zoek ik op Car bij title, en voor action & comedy in tags.
Nu was voor het volgende belangrijk, de volgorde van de tags bepalen de weergaven (van meest relevant tot minder).
Als ik bijvoorbeeld comedy voor action zou zetten, wordt een film met comedy als eerste gegeven tag, eerder getoond. Waarom? Nou heel eenvoudig, een bepaalde film/serie, is bijvoorbeeld meer drama, en maar een beetje actie.

Met FULLTEXT() kun je op basis daarvan een score berekenen, en krijg je dus heel mooie resultaten.
Doordat ik deze direct in SQL doe, heb ik geen gedoe met een controller/model schrijven, de query wordt namelijk mooi berekend op de basis en dat scheelt dus weer performance-verlies.

Dan heb je een keer het nadeel van FULLTEXT(); deze bouwt namelijk een index op, iets wat je niet tot nauwelijks kan met relaties. Dan krijg je inderdaad de situatie die jij schets: stel ik wil de tag dramas veranderen in drama, dan moet ik dit record-per-record aan gaan passen.
Echter los ik dit met een FULLTEXT ook weer op, omdat deze dus mooi voor mij een index heeft opgebouwd en dus de records 'supersnel' kan ophalen, echter moet daarna weer de index worden rebuild, maar ook dit gebeurd automatisch.

Zoals je ziet komt nergens een JSON voor, of nergens iets waar ik iets omzet.
Ik haal simpel de data op met een fetchAll();

Nu even terugkomen op het punt waar we het over hebben.
Stel je wilt het volgende resultaat:

code:

Movie Titel|Tags: 1 => tag1, 2 => tag2, 3 => tag3

Als ik jou verhaal volgt, wil je eerst dat ik alle records ophaal, en vervolgens de tags ophaal met weer een functie. Tenminste zo hoe ik het interpreteer.

code:

foreach:
  $movie = $this->getMovie();
  $tags = $this->getTags($movie['id']);
end foreach;

Of bedoel je het anders?
Met een JSON of zoals RM-rf aangeeft (Tags: tag1,tag2,tag3), kan je die data ook in één keer meegeven aan je SQL.
Waarom zou je dan nogmaals de data dubbel gaan ophalen? De kracht van SQL zit hem juist in het zoeken en verwerken van records.
Waarom trouwens JSON, omdat ik dit wilde doen:

code:

[
   1 => [
       'name' => tag1,
       'display' => Tag 1
   ],
   ...
]

Met een JSON kun je heel eenvoudig die data doorgeven aan je presentatie laag, maar ook aan je PHP-code. In Twig kan je eenvoudig json_decode() toevoegen en vervolgens een mooie for aanroepen.
Ik zie daarom niet het probleem, en begrijp daarom niet dat je nogmaals een extra laag wilt toevoegen.
Die json_decode levert je echt geen problemen op, sterker nog, die functie is sneller dan unserialize.

Mijn vraag dus aan jou, zou je dit dan echt oplossen met een extra ('Tag') laag?

Bedankt voor je input.

[Cartman!]

HollowGamer schreef op dinsdag 17 mei 2016 @ 09:54:
<snip>

Zoals je ziet komt nergens een JSON voor, of nergens iets waar ik iets omzet.
Ik haal simpel de data op met een fetchAll();

Nu even terugkomen op het punt waar we het over hebben.
Stel je wilt het volgende resultaat:

code:

Movie Titel|Tags: 1 => tag1, 2 => tag2, 3 => tag3

Als ik jou verhaal volgt, wil je eerst dat ik alle records ophaal, en vervolgens de tags ophaal met weer een functie. Tenminste zo hoe ik het interpreteer.

code:

foreach:
  $movie = $this->getMovie();
  $tags = $this->getTags($movie['id']);
end foreach;

Of bedoel je het anders?

Het voorbeeld van NMe laat volgens mij zien dat je in 1 query simpel kunt zoeken op tags, daarna kun je simpelweg per film alle tags ophalen als je dat zou willen om te presenteren.

Met een JSON of zoals RM-rf aangeeft (Tags: tag1,tag2,tag3), kan je die data ook in één keer meegeven aan je SQL.
Waarom zou je dan nogmaals de data dubbel gaan ophalen?

Jij bedoelt dat je doordat je de fulltext gebruikt nu altijd alle data al kan terugkrijgen en daarom niet meer los hoeft te querien op de tags? Je kan eventueel gewoon n subquery gebruiken om dit ook in 1 query te mikken met een koppeltabel, geen probleem.

De kracht van SQL zit hem juist in het zoeken en verwerken van records.

Precies, daarom is zoeken op tags ook zo efficient als je ze maar opslaat als tags in n koppeltabel. Je noemt een paar keer performance als reden het op deze manier te willen doen maar fulltext is zoveel trager dan een paar joins op primary key. Nu zal je daar niet zoveel van merken maar als je meer en meer records hebt dan zal het steeds trager worden omdat ie elke record langs moet om te matchen, daar heb je met een koppeltabel simpelweg geen last van.

Waarom trouwens JSON, omdat ik dit wilde doen:

code:

[
   1 => [
       'name' => tag1,
       'display' => Tag 1
   ],
   ...
]

Met een JSON kun je heel eenvoudig die data doorgeven aan je presentatie laag, maar ook aan je PHP-code. In Twig kan je eenvoudig json_decode() toevoegen en vervolgens een mooie for aanroepen.
Ik zie daarom niet het probleem, en begrijp daarom niet dat je nogmaals een extra laag wilt toevoegen.
Die json_decode levert je echt geen problemen op, sterker nog, die functie is sneller dan unserialize.

Je gaat dan iets encoden naar json om het vervolgens weer te decoden en alsnog te loopen, dat is toch een tussenstap teveel? Je doet toch de query die je data als php array of object teruggeeft? Dan kun je daar toch direct doorheen loopen?

Mijn vraag dus aan jou, zou je dit dan echt oplossen met een extra ('Tag') laag?

Absoluut zou ik hier n losse tabel voor willen ja. Stel je wil tonen hoeveel films je met een bepaalde tag wil, ga je dan voor elk dingetje die fulltext() pakken, of liever like()? Allemaal performance killers die totaal overbodig zijn als je gewoon joins gebruikt. Autocomplete op tags zal ook lastig zijn, welke tags heb je immers allemaal in gebruik? Dat weet je niet totdat je al je records gaat ophalen en per woord gaat kijken of je die al gebruikt totdat je een lijstje kunt weergeven.