Sziasztok!
Webshop rendszerben vitatkozunk azon, hogy a kategoriakat milyen rendszerben kellene letarolnunk. MySQL-t hasznalunk, es PHP-ben irjuk a site-ot.
Az adjacency modelben ugye rekurziv a lekerdezes, viszont az insert rohadt gyors, a nested setben pedig a select egyszeru es gyors, az insert viszont szopo, mert le kell updatelni mindent.
Nem tudom, melyik erne meg jobban, mert ugye par tizezer webshop-lekeresre szamithatunk napi szinten - legalabbis napi 10 000+ unique visitort irtak a doksiban (mukodo site-ot cserelunk le egy nagyobb cegnek), viszont az admin is egy erdekes allatfaj, szoval ki tudja, mennyire fogja baszogatni a kategoriakat, ha rajon, milyen szep az a drag and drop.
Gondoltam, le kellene benchmarkolni, de ahhoz meg kellene irni mindket adatszerkezetet es fel kellene tolteni random adattal, aztan ki kellene szamolgatni, milyen aranyoknak kell lenni, ahol meg jobban megeri a nested set model, viszont azzal elbasznek egy napot, es a tobbiek az adjacency list modelben hisznek amugyis, az en revolutionary ujitasom lenne (bar az otlet nem az enyem).
Szoval gondoltam, eloszor itt kerdezem meg, hatha valakinek van tapasztalata ezzel kapcsolatban, es ha itt van a tema, talan mas is okulhat belole legkozelebb :)
- 2007 megtekintés
Hozzászólások
Nested set. Én sok időt töltöttem mind a három adatszerkezeti típussal, kipróbáltam őket, de csak a nested set alkalmas hierarchikus adatok normális tárolására és lekérdezésére. Adjacency esetén nem tudod SQL-ben lekérdezni normálisan a teljes fát (mélységi korlát nélkül), tehát vagy írsz rá valamilyen SQL függvényt, vagy lekérdezés után pl. PHP-ban rendezed, ami sok kategória esetén elég sok erőforrást vesz el. A path enumeration nagyon egyszerű, könnyű használni (akár select, akár insert esetén), viszont a siblings-ek rendezése nagyon nehéz, mert kell hozzá pl. egy ordering oszlop, de mi több nap alatt sem tudtunk olyan select-et írni, ami az ordering szerint rendezve adja vissza a fát. A nested set bonyolultabb algoritmusokat használ, viszont semmi probléma nincs vele, mindent meg lehet oldani vele. Ráadásul nagy forgalom esetén is jobb, mert ahogy te is írtad, a select nagyon egyszerű, és egy forgalmas oldalnál a select számít, nem pedig az insert és az update (amit az admin néhanapján elvégez). Sok megírt kód van hozzá, szóval implementálni sem olyan nehéz. Személy szerint én ezt a kódot szoktam venni alapul ha valahova be kell építenem: http://www.edutech.ch/contribution/nstrees/
- A hozzászóláshoz be kell jelentkezni
Hmm kosz a linket, hasznos lesz azt hiszem :) Kollega mar teszteli is :)
- A hozzászóláshoz be kell jelentkezni
Esetleg érdemes megnéznetek a Doctrine-t is, van benne integráltan Nested Set implementáció.
Üdv,
Gergely
- A hozzászóláshoz be kell jelentkezni
+1
mptt a default valasztas hierarchikus adatok adatbazisban valo tarolasara.
- A hozzászóláshoz be kell jelentkezni
Ha megvan, hogy az adatbázis query vagy transaction intensive lesz a kiszolgálandó alkalmazás jellegét tekintve, akkor meglesz szerintem a megfelelő adatszerkezet is.
- A hozzászóláshoz be kell jelentkezni
Nem akarlak Benneteket (nagyon) cikizni, de nem gondolátok, hogy "pár" lényeges szempontot ki és lehagytatok?
Mint például..
.. mennyi a kategóriák száma.. ami nem mindegy, hogy 100 vagy 10 000
.. milyen megjelenítéseket alkalmaztok a kliens oldalon.. ugyanis lehet piszok gyors egy nested tree, ha utána komoly átalakításra van szükség, hogy megjelenítsd
.. hol a "régi" harmadik adatstukatúra (path), amely gyors select-et és gyors insert-et produkál.. vagy féltek, hogy 1-10MB-al nagyobb lesz a tábla?:)
..
Ezek ismerete nélkül komolytalan a kérdés az összes (eddigi) válasz.. bár inkább a vicces jobb szó.
- A hozzászóláshoz be kell jelentkezni
bocs, elfelejtettem irni, 100-200 kategoriaval szamolunk, megjelenitessel nincs gond, es a path enumerationnel meg szopo a php-s implementacio (meg esetleg lassabb is valamivel).
- A hozzászóláshoz be kell jelentkezni
100-200 tétel esetén szinte tök mindegy miben tárolod.. ez nem tétel.
Szerintem mind a két implementációval csak szopatjátok Magatokat, mert nem tudom elhinni, hogy ne egy kész, kitalált kategória modellel dolgozzon egy ilyen oldal, tehát a módosítás nyilván elenyésző lesz. Igazából én azt sem értem, hogy ekkora mennyiségnél.. komolyan mindig, vagy minden egyes látogatónál le akarjátok kérdezni az adatbázis?
Semmi értelme és erőforrás zabáló.
Nem ismerem ugyan se a php-t, se a mysql-t, de meglepne ha a path-os megoldás nem lenne sokkal egyszerűbb mint a felsorolt kettő..
Egy fél éve terveztem egy táblát 100-10000/nap növekedéssel számolva és akkor utánanéztem mivel érdemes megcsinálni.. én végül a path-osnal maradtam, mert bár nem helytakarékos, ellenben egy felvitt rekordnál (bizonyos esetekben) nincs semmi módosítás és mind az select mind az insert gyors.. és ezek voltak a legfontosabb az adott szempontok a működési környezetben.
Ennél a tételnél viszont tényleg csak az számít, mennyire vagytok ügyesek.. ha eléggé akkor select csak akkor kell, ha módosítás van, egyébként meg cache-ből van kinyomva.. a több, hogy miben tárolod a lényegtelen kategória.
- A hozzászóláshoz be kell jelentkezni