DevProTalk - Koji je dizajn baze najbolji, za kategorije koje su u parent-N-child vezi?

DevProTalk (http://www.devprotalk.com/index.php)

- SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)

- - Koji je dizajn baze najbolji, za kategorije koje su u parent-N-child vezi? (http://www.devprotalk.com/showthread.php?t=5454)

Koji je dizajn baze najbolji, za kategorije koje su u parent-N-child vezi?

Cao,

Imam nešto ovako.
Postoji tablica lokacije, u kojoj su premljene informacije o lokacijama(naziv, adresa, kordinate itd).
Svaka lokacija može biti vezana sa 0 ili više kategorija(ovo je tipična NxN veza i to mi nije problem).
Problem mi je malo kod kategorija. Nazivi kategorija su npr. smještaj, hotel , kuća, 4zvjezdice, 3 zvjezdice, 2 zcjezdice, banke, bankomati, rent, skuter, auto.
Naravno postoji i logicka veza izmedu pojedinih kategorija.

Kôd:

Smještaj

    Hotel

        4 zvjezdce

        3 zvjezdce

        2 zvjezdce

Banke

    Bankomati

Rent

    Auto

    Skuter 

    Brod

Imam oko 100 kategorija, ovo je samo pojednostavljeni primjer.

Znaci postoje root kategorije, što je u ovom primjeru, Smještaj Banke i Rent.
Samo su sa zadnjom kategorijom vezane lokacije, znači lokacija može biti vezana za 4 zvjezdce, 3 zvjezdce, 2 zvjezdce, Bankomati, Auto, Skuter, Brod.
A između root kategorije i zadnje kategorije, može biti N pod kategorija.

Meni trenutno kategorije u bazi funkcioniraju na sljedeci nacin. Postoji tablica Kategorije i ona ima 2 polja, Id i naziv.
Problem ovoga je sto u bazi nemam nikakvu vezu oko toga kako su povezane kategorije, ta logika mi je hard-codirana u preko 100 fajlova i skoro toliko isto direktorija, kako smo dosli do toga ne bi o tome:1089:

Ja imam par ideja kako da to pojednostavim, pa me zanimaju tuđa mišljena, po mogučnosti bih htio naci neki srebreni metak za ovakav problem.

IDEJA 1.
Da napravim konfiguraciski fajl, xml, u kojem bi mi bile veze između kategorije, nešto tipa

Kôd:

<root>

<kategorija>

<id>45<id> #ovo bi mi bio id iz baze

<naziv>Smještaj<naziv>

<pod_kategorija>

    <kategorija>

    <id>80<id> 

    <naziv>Hotel<naziv>

    <kategorija>

        <pod_kategorija>

        <kategorija>

        <id>42<id>

        <naziv>4 zvjezdce<naziv>

        <kategorija>

        <kategorija>

        <id>41<id>

        <naziv>3 zvjezdce<naziv>

        <kategorija>

        <kategorija>

        <id>43<id> 

        <naziv>2 zvjezdce<naziv>

        <kategorija>

        <pod_kategorija>

<pod_kategorija>

<kategorija>

Prednost:
Na ovaj nacin bi mi cijela logika bila u jednom fajlu.
Nedostatak:
Ako se doda nova kategorija, moralo bi se ručno prepraviti taj xml fajl.

IDEJA 2.
Prosiriti tablicu kategorije sa:
moze_imati_lokacije (DA/NE)
njegova_nad_kategorija(id on nad kategorije ili N/A)

Prednost:
U bazi bi mi bila logika, kako su kategorije vezane.
Nedostatak:
Nešto mi govori da ovo baš nije način na koji se baze trebaju koristi.
Morao bih napisati neku klasu koja bi prosla kroz cijelu tablicu kategorije i napravilia takvu strukturu u memoriji.

IDEJA 3.
na napravim više tablice tipa: root_kategorija, pod_kategorija1, pod_kategorija2, pod_kategorija3, do jedno 4 ili 5, ne mislim da ce više biti.
Prednost:
Ne vidim nikoju. Ova mi se ideja ne sviđa. možda samo osobno mišljenje.

Kada sada malo razmislim, možda je moje pitanje najbolje preformulirati i postaviti ga na način: Kako se struktura stabla(tree) sprema u bazu ?

Ako ste sve oko procitali, hvala vam na trudu, ako i niste svejedno hvala na pomoci...

Pročitao sam post dva puta :) ali opet sam možda nešto propustio :)

Ovo je klasičan primer predstavljanja hijerarhije u relacionoj bazi.

Ako je zadovoljen uslov da jedna kategorija može imati samo jednog roditelja, rešava se sa:

kategorija: id, naziv, id_parent (id_parent = null -> root kategorija)

Ako jedna kategorija može da ima više roditelja (odnosno list možeš da prilepiš za više od jedne grane), onda se dodaje vezna tabela:

kat_relations ( id_parent, id_child)

U skladu sa izabranim rešenjem i napraviš rutine koje ti crtaju / dovlače podatke za stablo (rekurzivne ili iterativne, šta više voliš).

Šta misliš?

Ideja 3 ni u ludilu! Nemoj ni da pomisljas vise na takve stvari! :D

Ideja 1 bi mozda mogla proci, ukoliko ti je jako bitna brzina izvrsavanja i ukoliko ne mijenjas cesto kategorije. Znaci, parsujes XML fajl (vjerujem da je relativno brze, nego da izvrsavas hijerarhijske upite u bazi za svako ucitavanje stranice) i prikazujes kategorije i druge elemente iz XML fajla. Jos kad bi to mogao nekako cacheovati...

Ideja 2 je najcesce koristena i ima najvise logike za tu potrebu. U Oracleu vec odavno postoje naredbe za koristenje hijerarhijskih upita (CONNECT BY ...), a u MySQL-u se radi na tome.

kada covik ovako utroši uru vremena da napise pitanje i samomu mu postanu jasne neke stvari....

otisao sma malo googlati

i pronasao http://www.sitepoint.com/article/hie...data-database/

opisana su 2 rijesenja toga problema

Citat:

Originalno napisao DejanVesic (Napišite 55330)

Ako jedna kategorija može da ima više roditelja (odnosno list možeš da prilepiš za više od jedne grane), onda se dodaje vezna tabela:

kat_relations ( id_parent, id_child)

Ok shvacam ali onda ovo nije vise struktura stabla, da li znaš kako se ovakva struktura zove ?

Graf.

Inače, drugo ili prvo rešenje, a verovatno drugo. Obično je zgodno i da se stablo kategorija kešira u memoriji, jer se relativno retko edituje.

Citat:

Originalno napisao jablan (Napišite 55339)

Graf.

Inače, drugo ili prvo rešenje, a verovatno drugo. Obično je zgodno i da se stablo kategorija kešira u memoriji, jer se relativno retko edituje.

je mozes dati neki link u vezi toga, shvacam koncept, samo kao to u PHP-u...

Za keširanje pitaš? Nisam baš neki stručnjak za PHP, ali pretpostavljam da možeš da koristiš static promenljive za to, i da kategorije ponovo učitaš kadgod se promene.

Sad, neko sofisticiranije rešenje za invalidaciju keša bi verovatno podrazumevalo neki sistem observera, a verovatno neki PHP frejmvork obezbeđuje sve to (i keširanje i invalidaciju, a moguće i kompletan rad sa hijerarhijskim strukturama).

Jablan je sve lepo odgovorio, da, graf.

Koje ćeš rešenje izabrati isključivo zavisi od biznis zahteva; ako nema šanse da se list kači na više od jednog drveta, onda prvo - jednostavnije je i za implementaciju i za održavanje.

Ako taj uslov nije ispunjen, onda drugo.

Keširanja ima milion; od najprostijeg "dohvati sve što treba iz baze, napravi php / xml fajl i od sada pa nadalje koristi njega" do najkomplikovanijih, koji sve čuvaju u memoriji i slušaju promene itd.

Za početak idi bez keširanja; kada sve funkcionalno proradi, onda razmišljaj o optimizacijama.

Citat:

Originalno napisao DejanVesic (Napišite 55343)

Ako taj uslov nije ispunjen, onda drugo.

Pa sad, i nije neophodno da koristi grafove ako mu treba višestruka pripadnost - dovoljni su tagovi. Mnogo se lakše implementiraju, a često hijerarhija i nije preterano bitna.

Kesiranje je jako vazno ako ima puno kategorija. Imam jedan sajt gde je klijent napravio preko 1000 kategorija koje idu do 6. nivoa u dubinu. Ja generalno pokupim sve kategorije i onda ga promuljam, napravim stablo preko rekurzije i sacuvam u cache file kao obican php array.

Kase se regenerise samo kada on iz administracije promeni nesto u kategorijama, doda novu, izmeni postojecu ili obrise neku.

Ako ima malo kategorija, onda i nije kriticno, mada je lepo da se kesiraju te stavke koje se ne menjaju cesto. Opet, zavisi i od posete, ako ima 10 ljudi dnevno, nema ni neke potrebe za kesiranjem.

Ja sam inace isao "ne-skolski", pa sam u svakoj kategoriji napravio dodatna polja, pored parent_id koji je id "roditeljske" klategorije, imam i "parents" koji drzi sve "roditelje" te kategorije do glavne kategorije, pa tako ako imam kategoriju koja je u 4. nivou, u parents stoji "9,125,903".

Pa ako hoces da prikazes celu granu do vrha radis SELECT * FROM cat WHERE cat_id ON (parents), kao sto rekoh nije skolski ali ubrzava posao.