Jak navrhnout strukturu

Me jako prvni napadlo: "proč si probůh beres zakázku, ke ktere nevis jak přistoupit"?

No, myslím, ze nez by to někdo dělal za tebe, mel bys zvolit aspon opačný postup - něco zkus a pak se to propadne upraví.

raddimm.xx:
1,5M položek je dost teda. Pokud vůbec nevíš jak na to, tak se tomu obloukem vyhni, předejdeš problémům.
Bude potřeba sofistikovanější řešení (traverzování stromu a určitě i kešování a bůhvi co ještě, netroufám si ani tvrdit, že PHP a MySQL k vykreslení takového stromu bude to pravé ořechové).


Jinak ta nejzákladnější podoba bude Id |Name | ParentId , ale ty budeš asi potřebovat něco složitějšího.

Co konkrétně je problém? Zkoušel jsem v MySQL intervalový dotaz s indexem na 1,5 M záznamů a trvá to jednotky milisekund. Na traverzování kolem stromu (které už zřejmě používáš) nic jiného potřeba není, ne?

Rekurzivní dotaz přes parent_id jsem nezkoušel, nemám tu dostatečně novou verzi MySQL/MariaDB. Očekávám, že to s indexem bude pořád použitelné.

Kcko:
„Bude potřeba sofistikovanější řešení“
Proč?
Mně 1,5 milionu položek nepřipadá nějak moc v tom smyslu, že by to nutně naráželo na nějaké technologické limity.

Ostatně, podle mě samotný počet položek o složitosti nic moc neříká, i databáze o desítkách miliard záznamů může být bez problému rychlá, naopak databáze s 500 záznamy může být pomalá.

„netroufám si ani tvrdit, že PHP a MySQL k vykreslení takového stromu bude to pravé ořechové“
Proč, v čem je takové řešení problematické?
Když ta technologie utáhne Facebook nebo Wikipedii, proč by to měl tady být problém?

raddimm.xx:
Čili každý díl má kategorii a kategorie jsou organizované do stromu?
A typický dotaz bude zobrazit díly přímo v zadané kategorii a díly uvnitř (stromu) zadané kategorie?

Tak kdybych měl kategorie např.:
A
┣ B
┃┗ C
┗ D
E
┗ F

(a jednotlivé položky, kde každá patří do určité kategorie)

Dokud potřebuji vybrat jen položky v nějaké kategorii (např. položky jejichž kategorie je A) a případně se navigovat mezi kategoriemi (tj. potřebuji vědět, že v kategorii A jsou kategorie B a D, nebo že kategorie F patří do kategorie E), je to triviální.
V podstatě by stačilo si u každé kategorie držet ID rodiče.

Problém nastane s dotazy typu „všechno uvnitř kategorie“, tj. např. díly v kategorii A jsou všechny, které mají kategorii A, B, C nebo D.
Na to se dobře hodí algoritmus traverzování kolem stromu (možná by se mu dalo říkat „algoritmus obkreslování stromu“), viz např. zde: www.zdrojak.cz/clanky/ukladame-hierarchicka-data-v-databazi-ii

S tímhle algoritmem je mnohem jednodušší číst strom.
Nevýhodou je o něco málo pomalejší přidávání kategorií (jsou to 2-3 kroky: Pokud nemáme údaje o rodiči už předtím, potřebujeme jeho pravý index, abychom zjistili indexy nové položky. Potom všechny indexy větší nebo rovné dosavadnímu pravému indexu rodiče zvýšíme o 2, čímž se udělá místo pro novou položku. A nakonec se vloží ta nová položka).
Výkonově nejnáročnější operace je přepočítání stromu, což naštěstí stačí udělat jen jednorázově.

Jinak výpočetní náročnost nezávisí na počtu položek, ale na počtu kategorií a počtu úrovní zanoření.