Ako efektivne na vnoreny vypis kategorii z roznych tabuliek?

Mohol by mi prosim niekto poradit.Riesim vypis vnoreneho zoznamu z 3 roznych tabuliek. Lepsie by to bolo z jednej tabulky, struktura udajov to ale neumoznuje.Momentalne to riesim nasledovne:// vypis 1 .urovne$result=mysql_query("SELECT * FROM categ");while($row=mysql_fetch_array($result)) { echo $row."
"; // vypis 2. urovne $result_2=mysql_query("SELECT * FROM subcateg WHERE categ_id={$row}"); while($row_2=mysql_fetch_array($result_2)){ echo "---".$row_2."
"; // vypis 3. urovne $result_3=mysql_query("SELECT * FROM subsubcateg WHERE subcateg_id={$row_2}"); while($row_3=mysql_fetch_array($result_3)) echo "------".$row_3."
"; }}Napriklad:Z toho vyplyva, ze 1 Query (SELECT) bude na vypis kategorii.Podla poctu kategorii budu dalsie Query (SELECT) pre subakategorie, napr. 10.A podkategorii bude 50, takze bude aj 50 Query (SELECT).Dokopy 61 Query poziadaviek na DB.Nepozdava sa mi to z hladiska optimalizacie, co sa tyka poctu poziadaviek na DB.Mohol by mi niekto prosim poradit ako by sa to dalo riesit efektivnejsie?Napr. cez 1-4 Query?Vysledna struktura by mala byt napr.1.- 1.1.--1.1.1.--1.1.2.--1.1.3.-1.2.--1.2.1.--1.2.2.--1.2.3.2.-2.1.-2.2.... 10.

Ďakujem

jestli to spravne chapu, tak vypisujes vzdycky vsechny, takze proc ti nestaci tohle? select a.*, b.*, c.* from a, b, c where b.a_id = a.id and c.b_id = b.id a potom to jeste nejak opracujes, aby se to dalo lehce zobrazit... jinak nezapomen na to, ze vetsinu pomalych dotazu lze vyvazit rozumnym cachovanim...

mit 3 tabulky pro kategorie a to tak ze kazde vnoreni potrebuje novou tabulku je tutove spatny navrh databaze - struktura dat na 100% umoznuje mit data v jedne tabulce - otazka je, proc je tak nemas... kazdopadne vedouci napsal dotaz ktery by ti mohl pomoci a zminil cachovani, ktere se urcite muze vyplatit a doporucuji ho vyuzivat (dokaze zatez aplikace stahnout na skutecne minimalni hodnoty, kterych neustalym opakovanim pomalych dotazu nemas sanci dosahnout)

Pokud rád vyžíráš server, tak si vymysli jednu tabulku (se sloupcem např. level) a projížděj to rekurzivně. Pokud nejsi líný napsat si třídu pro práci s kategoriemi ve stylu "traverzování kolem stromu", tak je to mnohem rychlejší.

:) nebo pouzit uz hotova reseni (google poradi) sam vyuzivam traverzovani, ale cache to stejne resi nejlip :D

Taky možnost. Já si ale radši píšu vše sám, nemusím potom někde poslouchat, že něco kopíruju a že nic neumím. Zabere to sice čas, zato svůj skript absolutně znám, a jeho úprava je tak pro mě jednoduchá.

Napsal pr0gr4mm3r;530084

Pokud rád vyžíráš server, tak si vymysli jednu tabulku (se sloupcem např. level) a projížděj to rekurzivně.

Pokud nejsi líný napsat si třídu pro práci s kategoriemi ve stylu "traverzování kolem stromu", tak je to mnohem rychlejší.

muzes mi prosim vysvetlit, jakou to ma vyhodu proti cache? protoze me prijde, ze sis akorat nekde precetl, ze je to cool reseni - pravdepodobne u vrany a pritom si nedomyslel vsechny nevyhody... (o kterych se tam samozrejme nepise)

Špatně jsi mě odhadl. Vyzkoušel jsem více způsobů jak na to. Teď je tu popíšu: 1)Dotaz pro každou úroveň zvlášť Funguje to na podobném principu, jak je v úvodním příspěvku. Mám prostě tabulku s názvem kategorií, její úrovní, a rodičem. Poté provádím jednotlivé dotazy na databázi, poprvé na úroveň 1, potom na úroveň 2,.. Nevýhody: - Pro každé zanoření musím mít vytvořený cyklus, takže zanoření je omezené. 2)Rekurzivní funkce Struktura DB stejná jako v bodě 1. Pouze volám rekurzivně, předávám si různě parametry. Výhody: - Neomezené zanořování. - Dá se hezky zavolat, vytvořit si drobečkovou navigaci bez práce,... Nevýhody: - Obrovská náročnost na výkon, hlavně pokud je více zanoření. Pokud vypisuji menu, tak to trvá strašně dlouho - hodně dotazů na DB. 3)Traverzování kolem stromu Struktura DB obsahuje levé a pravé číslo. Nebudu to tu popisovat do podrobna, ale pořadí kategorií v menu (se zachováním úrpvní, apod.) je stejné jako pořadá levého čísla. Výhody: - Vysoký výkon - výpis pouze seřazením tabulky, pro výpis menu stačí 1 dotaz. Nevýhody: - Složité pro úpravy kategorií - musí se přečíslovávat levé a pravé čísla, a nad tím se musí už hodně zauvažovat. Nevím, jak jsi to přesně myslel s cache, zkus rozepsat. Napadá mě třeba možnost vytvořit menu jedenkrát a uložit do souboru ve statické formě, a soubor občas auktualizovat. Tam ovšem vidím hromadu nedostatků - nemůžu zvýraznit aktuálně zobrazenou kategorii, nemůžu provádět dotazy pro vytváření hezké url. Např. pro vytvoření hezké url je traverzování hodně rychlé. O traverzování jsem se dozvěděl pomocí googlu, kde jsem hledal způsob, jak udělat menu co nejrychleji. Hledal jsem v anglické části internetu, později jsem objevil i článek u zaachiho, kde jsem načerpal hodně teorie.

Napsal pr0gr4mm3r;530133

Špatně jsi mě odhadl.

Vyzkoušel jsem více způsobů jak na to. Teď je tu popíšu:

1)Dotaz pro každou úroveň zvlášť

Funguje to na podobném principu, jak je v úvodním příspěvku. Mám prostě tabulku s názvem kategorií, její úrovní, a rodičem. Poté provádím jednotlivé dotazy na databázi, poprvé na úroveň 1, potom na úroveň 2,..

Nevýhody:

- Pro každé zanoření musím mít vytvořený cyklus, takže zanoření je omezené.

2)Rekurzivní funkce

Struktura DB stejná jako v bodě 1. Pouze volám rekurzivně, předávám si různě parametry.

Výhody:

- Neomezené zanořování.

- Dá se hezky zavolat, vytvořit si drobečkovou navigaci bez práce,...

Nevýhody:

- Obrovská náročnost na výkon, hlavně pokud je více zanoření. Pokud vypisuji menu, tak to trvá strašně dlouho - hodně dotazů na DB.

3)Traverzování kolem stromu

Struktura DB obsahuje levé a pravé číslo. Nebudu to tu popisovat do podrobna, ale pořadí kategorií v menu (se zachováním úrpvní, apod.) je stejné jako pořadá levého čísla.

Výhody:

- Vysoký výkon - výpis pouze seřazením tabulky, pro výpis menu stačí 1 dotaz.

Nevýhody:

- Složité pro úpravy kategorií - musí se přečíslovávat levé a pravé čísla, a nad tím se musí už hodně zauvažovat.

Nevím, jak jsi to přesně myslel s cache, zkus rozepsat. Napadá mě třeba možnost vytvořit menu jedenkrát a uložit do souboru ve statické formě, a soubor občas auktualizovat. Tam ovšem vidím hromadu nedostatků - nemůžu zvýraznit aktuálně zobrazenou kategorii, nemůžu provádět dotazy pro vytváření hezké url.

Např. pro vytvoření hezké url je traverzování hodně rychlé.

O traverzování jsem se dozvěděl pomocí googlu, kde jsem hledal způsob, jak udělat menu co nejrychleji. Hledal jsem v anglické části internetu, později jsem objevil i článek u zaachiho, kde jsem načerpal hodně teorie.

ano a pak je tady moje reseni - rekurze + cache vyhody - vsechny z rekurze + je to ve vysledku jeste rychlejsi nez traverzovani nevyhody temer zadne - jenom musis davat pozor na zneplatneni - kdyz se neco uklada do db, tak musis rict, ze tahle verze uz je neplatna a ze se musi menu poskladat z db znovu... jenom dodam - ze se to deje vzdycky jenom jednou a TUDIZ vsude, kde casteji volas dotazovani, nez update, budes profitovat z cache... muzes samozrejme cache pouzit i s traverzovanim, ale zustava ti ta koule u nohy ve forme specialniho pristupu uplne ke vsemu a zaroven mas jeste pomale updaty BTW: na skolach se uci regexy, sablonovaci systemy a kdejaka picovina, ale na cache si v osnovach nikdo nevzpomene... :-/

Teď je tu otázka, jak moc ta cache pomůže. Počítej s tím, že musíš kontrolovat aktualitu cache, něco musí obsluhovat cache. To taky není zanedbatelné, a efektivní to začíná být asi tak při více než 500 kategoriích (testoval jsem bez cache 100, a nevidím skoro žádné zpomalení). A pořád potřebuješ generovat SEO friendly url, rozklíčovávat dané url, dělat drobečkovou navigaci, a na to ti cache moc nepomůže.

v pripade aukcni sine pomaha stahnout request ze 150ms asi na 30ms, a to tam neni zadna rekurze...