3
Jan
Zařazení něčeho do kategorií …
Dneska jsem se dostal opět k velmi vtipnému řešení problému v relační databázi (to jsem to hezky napsal, ale ve skutečnosti jde o prasácky vyrobenou tabulku(y) vyústivší v prasácké selecty).
No schválně. Jak budete řešit přiřazení položky do kategorií? Ano, například jednoduchá tabulka (id_item, id_kategorie). Ale to je řešení běžné… Vskutku vtipné řešení, je přidat k položce sloupec, který obsahuje znakem, např. ‘|’, oddělené hodnoty. Pak máte velmi výkonný select ‘SELECT * FROM tabulka WHERE (kategorie LIKE ‘%|12345|%’) ORDER BY id’ (nad “select *” se již nepozastavuji).
No to si pak užijeme legrace s sql serverem, že? 
There's 10 Comments So Far
January 4th, 2008 at 18:54
Uz jsem se s tim setkal take, klepal jsem si na celo, jak to nekdo takhle mohl udelat. Ale pak mi jeden znamy ( db specialista ) vysvetlil, ze se timto zpusobem resi nektere zvlastni struktury. Myslim, ze zminoval “genealogike stromy” … ale vim houby, co to presne znamena
.
January 4th, 2008 at 20:12
No nevim presne, co je to genealogicky strom a jaka to ma specifika. Ale tady slo (bohuzel) o normalni ukladani do kategorii (jako treba v eshopu).
January 4th, 2008 at 20:59
Stromy se takhe ukládají docela efektivně (viz. http://blog.vyvojar.cz/arci/archive/2006/08/19/8995.aspx) ale i kategorie už sem viděl
January 4th, 2008 at 21:11
No strom bych si mozna dokazal predstavit, pac tam muzu jeste operovat s urovni a tim si trochu pomoci. Ale ja bych stejne delal leveho a praveho naslednika
(pro binarni strom). Deformace.
January 5th, 2008 at 01:47
Abyste nebyli zklamaní: Outlook 2xxx to v objektovém modelu dělá s kategoriema přesně takhle – oddělené středníkem (resp. podle lokále). Zajímavé je, že WebDavem je to přístupné jako pole hodnot.
January 7th, 2008 at 15:26
No, ja na tom zase nic tak hrozneho nevidim.Data mohou byt prece ulozena relacne (strom kategorii), Item s relaci na konkretni kategorii. Pokud budete chtit zobrazit seznam zbozi z urcite kategorie (rekneme SATA), tak to muzeme resit normalne pres SELECT c1, c2 FROM Item WHERE id_karegorie=@id_kategorie_SATA, ale jak to udelate pokud budete chtit zobrazit vsechny polozky z kategorie Pevne Disky ?MS SQL 2005 prinasi CTE (Common Table Expressions), ale drive se to IMHO bezne resilo pres redundantni sloupec v tabulce Item(napriklad prave |id_kategorie_PevneDisky|id_karegorie_Interni|id_kategorie_SATA|)seznam vsech pevnych disku pak je mozne ziskat jednim dotazem prave pres zmineny SELECT c1, c2 FROM Item WHERE karegorie_tree LIKE ‘%|id_kategorie_PevneDisky|%’.
January 7th, 2008 at 15:35
Toto lze vyresit pres jednu storku, nebo prave CTE nebo connect by (v ORA), … viz http://www.dbsvet.cz/view.php?cisloclanku=2007101201
Nicmene to ze nacpu do sloupce data nejak oddelena porusuju NF a take se mi rozpada referencni integrita mimo jine. Co se stane, pokud nejakou kategorii vymazu (pres SQL, v aplikaci A, v aplikaci B)? Musel bych si tohle “rucne” hlidat, nedej boze, aby zavislych tabulek bylo nekolik nebo se kaskadaovalo do hloubky >2.
Na ten LIKE taky nefunguje index. A pokud bude zarazeni hodne (dlouhy string) je i prochazeni retezce casove narocne (i kdyz ten index to zkripluje dozajista dost).
Podle me je to hrozne dost. Nehlede na to, ze se porovnavaji cisla jako retezce (kdyby tam byly acsii znaky kvuli treba SEO, tak viz dalsi) a delka toho sloupce muze byt pri hodne kategoriich extremni (ci prelezt implementacni limit).
January 9th, 2008 at 04:19
Strom do tabulky bych ukládal normálně metodou traversování kolem stromu. Není důvod to řešit takhle. Dodržuji NF i referenční integritu.
January 9th, 2008 at 09:28
2 BoneFlute> konecne nekdo, kdo je stejne zalozen
…
January 9th, 2008 at 23:20
Uz jsem se s tim setkal taky. Typicky si programator usetri jednu vazebni tabulku, jelokoz mu JOIN prijde narocnejsi nez parsovani stringu. U malych tabulek to jeste jde, ale u opravdu velkych tabulek je to hruza. Samozrejme, ze se na to nechytne zadny index. Pokud se pouzivaji genealogicke stromy, tak se vetsinou vyhledava LIKE ‘cesta%’ na coz se index chytne bez problemove. Pruser je opravdu v LIKE ‘%neco%’. Jinak pokud uz ma programator nutkani takovou skopicinu provadet, tak v pg muze pouzit pole – pak se neparsuje string, a navic se muze pouzit index, takze je to rychle.http://www.pgsql.cz/index.php/SQL_Triky#Indexov.C3.A1n.C3.AD_funkce_xpathResil jsem jeden shop, kde pro zmenu data mely ulozene v XML dokumentu.
Share your thoughts, leave a comment!