DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 27. 05. 2008.   #1
misko_
profesionalac
Qualified
 
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
misko_ is on a distinguished road
Question 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

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...
misko_ je offline   Odgovorite uz citat
Staro 27. 05. 2008.   #2
DejanVesic
old school
Professional
 
Avatar DejanVesic
 
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
DejanVesic će postati "faca" uskoro
Default

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š?
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/
DejanVesic je offline   Odgovorite uz citat
"Hvala" DejanVesic za poruku:
Staro 27. 05. 2008.   #3
Dejan Topalovic
old school
Professional
 
Datum učlanjenja: 15.02.2006
Lokacija: Wien, Austria
Poruke: 304
Hvala: 121
47 "Hvala" u 26 poruka
Dejan Topalovic će postati "faca" uskoro
Pošaljite poruku preko MSN za Dejan Topalovic
Default

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

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.
__________________
Blog: Baze podataka
------------------------
Oracle OCP DBA
Oracle OCE SQL Expert
Oracle OCP Developer
Certified MySQL DBA
Dejan Topalovic je offline   Odgovorite uz citat
"Hvala" Dejan Topalovic za poruku:
Staro 27. 05. 2008.   #4
misko_
profesionalac
Qualified
 
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
misko_ is on a distinguished road
Default

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 Pogledajte poruku

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 ?
misko_ je offline   Odgovorite uz citat
"Hvala" misko_ za poruku:
Staro 27. 05. 2008.   #5
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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.
__________________
blog
jablan je offline   Odgovorite uz citat
Staro 27. 05. 2008.   #6
misko_
profesionalac
Qualified
 
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
misko_ is on a distinguished road
Default

Citat:
Originalno napisao jablan Pogledajte poruku
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...
misko_ je offline   Odgovorite uz citat
Staro 27. 05. 2008.   #7
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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).
__________________
blog
jablan je offline   Odgovorite uz citat
Staro 27. 05. 2008.   #8
DejanVesic
old school
Professional
 
Avatar DejanVesic
 
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
DejanVesic će postati "faca" uskoro
Default

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.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/
DejanVesic je offline   Odgovorite uz citat
Staro 27. 05. 2008.   #9
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

Citat:
Originalno napisao DejanVesic Pogledajte poruku
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.
__________________
blog
jablan je offline   Odgovorite uz citat
Staro 27. 05. 2008.   #10
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.247 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default

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.
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
[WordPress] Is its parent directory writable? blackshtef Web aplikacije, web servisi i software 9 15. 10. 2008. 03:43
Parent - child fetch problem cvele SQL baze podataka - Sponzor: Baze-Podataka.net 13 01. 10. 2008. 17:08
2 pitanja u vezi MySQL-a i PHP-a u vezi datuma misko_ Sva početnička pitanja 16 17. 06. 2008. 19:04
Selektiranje stringa koji ima razmak iz MySQL baze uz pomoc PHP-a ??? misko_ Sva početnička pitanja 4 01. 04. 2008. 15:30
Event ponovno okinut na child elementima dee (X)HTML, JavaScript, DHTML, XML, CSS 7 29. 03. 2008. 12:41


Vreme je GMT +2. Trenutno vreme je 14:25.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.