|
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 |
|
Alati teme | Način prikaza |
27. 05. 2008. | #1 |
profesionalac
Qualified
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
|
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 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> 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... |
27. 05. 2008. | #2 |
old school
Professional
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
|
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/ |
"Hvala" DejanVesic za poruku: |
27. 05. 2008. | #3 |
old school
Professional
|
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 |
"Hvala" Dejan Topalovic za poruku: |
27. 05. 2008. | #4 |
profesionalac
Qualified
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
|
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 Ok shvacam ali onda ovo nije vise struktura stabla, da li znaš kako se ovakva struktura zove ? |
"Hvala" misko_ za poruku: |
27. 05. 2008. | #5 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
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 |
27. 05. 2008. | #6 |
profesionalac
Qualified
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
|
|
27. 05. 2008. | #7 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
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 |
27. 05. 2008. | #8 |
old school
Professional
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
|
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/ |
27. 05. 2008. | #9 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
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 |
27. 05. 2008. | #10 |
Goran Pilipović
Sir Write-a-Lot
|
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! |
|
|
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. 02:43 |
Parent - child fetch problem | cvele | SQL baze podataka - Sponzor: Baze-Podataka.net | 13 | 01. 10. 2008. 16:08 |
2 pitanja u vezi MySQL-a i PHP-a u vezi datuma | misko_ | Sva početnička pitanja | 16 | 17. 06. 2008. 18:04 |
Selektiranje stringa koji ima razmak iz MySQL baze uz pomoc PHP-a ??? | misko_ | Sva početnička pitanja | 4 | 01. 04. 2008. 14:30 |
Event ponovno okinut na child elementima | dee | (X)HTML, JavaScript, DHTML, XML, CSS | 7 | 29. 03. 2008. 11:41 |