Autor Zpráva
Petr1234
Profil *
Cau,

podle reseni uveden uzivatelem ronnie na http://diskuse.jakpsatweb.cz/index.php?action=vthread&forum=9&topic=44 193 jsem si udelal tabulku s menu, ktere nyni vypisuji na webu jako stromovou strukturu. Je to dobre reseni, dobre se s nim pracuje. Na webu mam treba:

Počítače
- Notebooky
- PDA
- Počítačové sestavy
PC komponenty
- grafické karty
- - AGP sběrnice
- - PCI-E sběrnice

a v tabulce ve sloupci zanoreni mam:

0001
- 00010001
- 00010002
- 00010003
0002
- 00020001
-- 000200010001
-- 000200010002

Aby se to vypsalo spravne, musim pouzivat ... ORDER BY zanoreni ASC. Jak mam ale docilit toho, abych to mel serazene podle sloupce name kde jsou nazvy kategorii? Kdyz pouziji ... ORDER BY name ASC udela to bordel. Proste podkategorie jsou pak prehazene.

Diky za radu
krteczek
Profil
ORDER BY name ASC, zanoreni ASC
ASC je mozno vynechat, je to defaultní řazení
Petr1234
Profil *
Hmm, toto buhuzel nefuguje :( Je treba mit na pameti, ze muzu pridat se sekce počitače novou položku, která se bude jmenovat třeba Barbone, ale ve sloupci zanoreni bude mit 0001003004, protoze jsou pred ni jiz 3 polozky...

Petr
Petr1234
Profil *
Oprava - bude mit zanoreni 000100030004 (zapomnel jsem tam nejake nuly...)

Petr
ronnie
Profil
No ja to ještě neřešil, ale udělal bych to asi takto:

Ze sloupce "zanoreni" bych pomocí funkce substring oříznul poslední 4 znaky a pak provedl setřízení jako

ORDER BY zanoreni, name
Petr1234
Profil *
No to asi moc nepujde. Proto, abych vypsal hlavni kategorii, pod-kategorii a podkategorii prvni podkategorie tak select z datbaze vypada takto:

SELECT * FROM category WHERE LENGTH(zanoreni)=4 OR zanoreni IN(0001) OR (zanoreni LIKE '0001%' AND LENGTH(zanoreni)=8) OR (zanoreni LIKE '00010002%' AND LENGTH(zanoreni)=12) ORDER BY zanoreni ASC

Jak by to slo upravit?

Richard
Azu
Profil *
tohle řešení je na ...
použij klasickou tabulku id, parent, text , celé to načteš jedním dotazem do pole a to pak v PHP seřadíš a je hotovo. Můžeš pak mít neomezený počet podvědtví
ronnie
Profil
Azu: přes parent by to bylo složitější, při větším zanoření musíš spojovat mnoho tabulek a jsou s tím ještě větší problémy. Obecně neexistuje jednoduché řešení, které by umožňovalo provádět všechny potřebné operace snadno.

Petr1234: a co to seřadit přímo v php přes nějakou funkci pro setřízení pole?
ronnie
Profil
Bylo by ale lepší to třídit přímo při vkládání...
DJ Miky
Profil
Tak třeba při tom SELECTu vyhodit poslední 4 znaky (nepamatuji si fci na to) ze sloupce zanoreni a jednoduchý SELECT s ORDER BY zanoreni,name;
tiso
Profil
Petr1234 sprav si na to triedenie (zmena poradia položiek) ako som si spravil ja a máš... http://tiso.wz.cz/tmp/db_menu/navigation2.php

bohužiaľ to je verzia s pár chybičkami, tú opravenú tu nemám...
Azu
Profil *
ronnie: co by na tom bylo složitější a už vůbec by mně zajímalo jaké problémy s tím mohou nastat? Jedním SQL dotazem stáhnu data a pak v PHP ty data setřídím. Tato metoda je složitější maximálně v tom, že ji nestáhneš hned na každém rohu na interentu, ale že je potřeba zapojit hlavu a naprogramovat to. Navíc se již jednou takto setříděné pole dá uložit do keše do souboru a příště není potřeba nic už třídit a tahat z DB.
ronnie
Profil
Jednim dotazem? Ok, tak sem takový dotaz napiš.

Jsem v eshopu, ve 4. podkategorii a znam pouze url. Jednim dotazem mi tedy vyber všechny položky, které se zobrazují v indexovém menu a všechny subpoložky, jejiž cesta vede od indexové položky k dané sekci. Zdůrazňuji, že jediné, co znáš, je URL, neznáš zanoření.

Dále zdůrazňuji, že se nebavíme o výpisu celé struktory, ale pouze určité subsekce. To by se přes genealogické stromy řešilo jako SELECT * FROM category ORDER BY zanoreni. Napiš mi dotaz, který tohle přes odkaz na parent řeší lépe a rychleji.

Napiš sem tedy tyto SQL dotazy a pak se budeme bavit dále.
Azu
Profil *
Vzhledem k tomu, že strukturu celého stromu na začátku musíš stejně načíst do pole kvůli následnému zobrazení, tak nebudeš přece šahat znovu do DB kvůli zjištění všech položek určité subsekce, ale provedeš to opět z toho načteného pole, které můžeš mít celé uložené na disku jako soubor, který slouží jako keš.
To řešení co si popisoval bude pro SQL server náročnější na zpracování a při určitém počtu oložik i pomalejší, než když kdybych rekurizivně projel položky určité větve, prootže budou ty položky indexovány.
ronnie
Profil
Vzhledem k tomu, že strukturu celého stromu na začátku musíš stejně načíst do pole kvůli následnému zobrazení

Nemusím, používám Zend_Db, které používá PDO s iterátorem. Výsledek dotazu můžu procházet přímo cyklem foreach, což také dělám.

To řešení co si popisoval bude pro SQL server náročnější na zpracování a při určitém počtu oložik i pomalejší, než když kdybych rekurizivně projel položky určité větve, prootže budou ty položky indexovány.

To snad ani nemyslíš vážně? Rekurze jsou pomalé jak čert, načítání souborů, serializace a pole, které obsahuje třeba tři stovky položek jen proto, že si chci vybrat 5 indexových položek?:)

Genealogické stromy jsou maximálně rychlé. Místo funkce LENGTH používám zvláštní sloupec pro zanoření, k němu přidám ještě index, takže načítání položek je maximálně rychlé.

Jinak výsledek také cachuji, protože v administraci nenabízím práci s položkami klasicky jako (v select elementu)
Hlavni
- podsekce
- podpodsekce

ale

Hlavní
Hlavní / podsekce
Hlavní / podsekce /podpodsekce

což je pro administratora přehlednější a vyplatí se takový výsledek cachovat. Zend_Cache mi pak automaticky kontroluje platnost cache, takže se o to vůbec nemusím starat.
Toto téma je uzamčeno. Odpověď nelze zaslat.