Autor Zpráva
raddimm.xx
Profil
Prosím o radu. Potřebuji pro e-shop s Autodily navrhnout databází pro strukturu dílu. Jde o klasicky strom, ale má cca 1 500 000 položek. A hloubku cca až 8

Se strukturou se kromě počátku moc nehybe. Nemění. Takže hlavně rychle čtení.

Na webu pak se nejčastěji vypisuje strom. Pod položky. A samozřejmě celá větev vzhledem k zařazeni.

Jak byste navrhli strukturu.

Ps mysql
Tomášeek
Profil
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í.
Kcko
Profil
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.
raddimm.xx
Profil
Tomášeek:
no je to trošku jinak než že jsem vzal zakázku, ale to je jedno.
Zatím to bylo řešené klasicky parent id, plus položka ve strukutře která naznačovala celou větěv: 76;4554;7765 s cca milionem polozek to bezelo nicmene některé operace pak byly dost náročné. Chtěl jsem se poradit o nějakém sofistikovaném a efektním a rychlém řešení :)
TomášK
Profil
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é.
Joker
Profil
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?
raddimm.xx
Profil
Joker:
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?
>> Ano klasický strom
>> A ano typický dotaz je zobrazit dily primo v zadane kategorii
>> Plus jeden dotaz je navic vypsat zařazení
Joker
Profil
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í.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: