Hierachical structures vs nested sets

Hi all,
As vrea sa pornesc o mica dezbatere, poate nu e locul cel mai potrivit dar cred ca e destul de interesant pentru toata lumea.
Din cate am vazut pana acum, foarte multi dintre voi lucreaza pe sisteme ecommerce si cu siguranta cred ca v-ati lovit de o problema de genul asta.
Ce preferati in ce priveste structura de db: hierachical data sau nested sets? Argumente ptr fiecare in parte sunt bine venite.
Pe aceeasi nota... care sunt abordarile voastre in ce priveste reportingul? Mergeti pe sistem OLAP (presupunand ca db-ul folosit suporta nativ) sau faceti un "simulacru" de cub?

Salut,

Folosesc de ceva vreme hierachical data. M-am folosit de articolul acesta: http://dev.mysql.com/tech-resources/...ical-data.html

Am mai adus eu cateva completari suplimentare, ex: sa activezi/dezactivezi o (sub)categorie, sa muti mai sus/jos. La un moment dat o sa vrei sa si ordonezi (sub)categoriile. Aici mi-am batut putin capul cu algoritmul pentru mutat, intr-un final mi-a reusit.

Daca doresti iti pot pune la dispozitie codul meu + structura bazei de date.

Citat:

---

Postat în original de VuePixel

Salut,

Folosesc de ceva vreme hierachical data. M-am folosit de articolul acesta: http://dev.mysql.com/tech-resources/...ical-data.html

Am mai adus eu cateva completari suplimentare, ex: sa activezi/dezactivezi o (sub)categorie, sa muti mai sus/jos. La un moment dat o sa vrei sa si ordonezi (sub)categoriile. Aici mi-am batut putin capul cu algoritmul pentru mutat, intr-un final mi-a reusit.

Daca doresti iti pot pune la dispozitie codul meu + structura bazei de date.

---

:).
Activare / dezactivare, mutat categorii, sortare sunt lucruri simple.
Eu vroiam sa pornesc o mica discutie privind avantajele si dezavantajele celor 2 abordari arhitecturale.
Una dintre problemele abordarii ierarhice este de exepmplu realizarea de count-uri real time pe un numar foarte mare de date (categorii) pe oricate nivele. Adica, sa presupunem ca trebuie sa afisezi numarul de produse dintr-o categorie si toate subcategoriile astfel incat sa realizezi un drill down (categorie [n produse] -> subcategorie [n-m produse] -> etc). Cum nu ai de unde sa stii pe cate nivele ai arborele nu poti folosi query-uri pe self si trebuie sa faci procesare recursiva programatic sau procedura stocata.
Eh.. abordarea de nested sets iti permite sa faci asta intr-un singur query.

Problema nr 2 referitoare la OLAP si simulacrul de cub. MySQL nu are suport de olap insa se poate simula un cub multidimensional bazat pe entitati si proprietati ale entitatilor.

Cam in directia asta ma gandeam sa mearga discutia. :)

Salutare,

Hirearchical data.

Ceva asemantor cu al lui VuePixel insa cu valori de stanga si de dreapta.
Ceva exemplu gasesti aici: http://articles.sitepoint.com/articl...ata-database/2

Ideea e in felul urmator:
- ai parent id-ul categoriei care te intereseaza
- in functie de valorile ei de left si right generezi tree-ul
- problema cu ordonarea dispare
- 2 query-uri: 1 pentru aflarea valorilor de stanga si de dreapta, 1 generarea tree-ului

Argumentele pro, pentru aceasta metoda, se afla in articolul mentionat mai sus.

Chaos: poti sa stii asta. faci un camp `level_id` in care stochezi : $parinte->level_id+1;

eventual, la add, valoarea asta o ai intr-un camp hidden.

mi-ar placea daca ai putea scrie un mic exemplu practic pentru chestia despre care zici ca nu se poate. nu sunt sigur daca am inteles bine.

sa zicem ca avem situatia asta:

+Masini ( id = 1, level_id = 1, left_id = 1, right_id = 6 )
++X ( level_id = 2, left_id = 2, right_id = 3, parent_id = 1)
++Y ( level_id = 2, left_id = 4, right_id = 5, parent_id = 1)

+Masini - au 7 produse
++X - au 3 produse
++Y - au 5 produse

asa vrei sa afisezi ?

Jur pe rosu ca daca nu dadea link @VuePixel catre articolul ala unde sa vada ochiul meu ce sunt "nested sets" nici macar nu te bagam in seama @Chaos :) pentru simplul motiv ca eu stiam de MPTT (Modified Preorder Tree Traversal) ... recomand articolul asta [Later Edit: acum am observat ca si @Gabriel Puscuta a dat acelasi link ... salut ;) ].

Asaaa ... acum ca vorbim de acelasi lucru ... cele 2 structuri se folosesc in situatii diferite. Fiecare are avantaje si dezavantaje.
Vorbind de MPTT, un mare dezavantaj este introducerea de date noi in structura care implica refacerea copacelului (a pozitiilor "left" and "right") pornind de la nodul inserat in jos. Clar, MPTT nu este pentru structuri foarte mari de date care se schimba in permanenta.

O alta problema (teoretica) ar fi utilizarea aceluiasi element in 2 pozitii din copac (cel mai simplu exemplu este un produs care se poate incadra in mai multe categorii).

Bineinteles, marele avantaj la MPTT este viteza cu care iei tot ce e sub un nod indiferent de numarul de nivele.

Si incet incet ne indreptam spre dezbatere.
Corect Dever, refacerea copacului presupune lock pe write pe tabela respectiva si trebuie refacute pozitiile in functie de ce s-a sters / adaugat / modificat. In ce priveste produsul in mai multe categorii... ma indoiesc ca ai sa tii produsele in aceeasi tabela cu categoriile si pentru asta oricum vei folosi un mediator intre produse si categorii. Daca o categorie are mai multi parinti... se schimba datele problemei. [chiar daca logic e putin probabil iar semantic cu atat mai putin].

nesting: viteza net superioara/ nu ai nevoie de parent_id / problematic de refacut tree-ul