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 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> 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:
|
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:
|
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:
|
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. |
Vreme je GMT +2. Trenutno vreme je 19:49. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.