Közben újabb elvi jellegû kérdés PHP/MySQL témában, ha valaki unatkozna:
Egy faszerkeszetbe rendezhetõ és kurvára flexibilis rekordosztályon dolgozom,tehát tulajdonképp egy elég fejlett node osztályon.
Ragaszkodnék egy egységes táblához, ami csak {id, szülõ, primitív név(url-hez pl), típus indexelt mezõkbõl és a data nevû, nem indexelt, típusonként tetszõleges 1 dimenziós stdClass/array-ból enkódolt JSON string mezõbõl állna.
Ez a "kurvára flexibilis" elvárásomat így teljesíti is, viszont a data mezõ értékei alapján való szûrés így nyersen nehézkes és teljesítménygyilkos lenne.
Találtam egy megoldást (le is kódoltam már amúgy így reggeli unalmamban :D):
Van egy segédindex tábla, saját id-vel, node id-vel, data-n belüli azonosító és érték párossal, ez a különbözõ írásmûveleteknél magától frissül ('DELETE FROM tábla WHERE nid=$this->id' illetve konstruktív mûveleteknél utána 'INSERT INTO tábla (nid,fname,fval) VALUES (...)').
Megoldottam a keresést is nagyon kényelmesen:
Van két szûrõ metódusom (illetve több is, de erre a kettõre alapulnak lustaságbarátabb shorthandek) az alap rekord osztályomban, azokat override-oltam, ha van data[valami_beágyazott_mezõ] (data majd szögletes zárójelben a beágyazott mezõ neve ha megenné a fórummotor BBCode-ként), mint mezõnév a lekérés paramétereiben, akkor az kicserélõdik egy "id IN (...)" feltételre a segédindex tábla lekérdezésének eredményei alapján, majd az megy tovább a szülõ osztály metódushívásába.
A kérdés tulajdonképp az lenne, hogy teljesítmény szempontjából szerintetek sikerült így a legoptimálisabb megoldást megtalálnom (+alkotnom) a problémára, vagy létezhez esetleg még valami jobb? A komplexebb, motorspecifikusabb adatbázistervezési eszközöket kerülném lehetõleg a széles futáskörnyezet-kompatibilitás védelmében.