[ sheik @ 06.05.2008. 13:23 ] @
Pozdrav svima,

Radim jedan property rent/sell sajt.
Svaki Property ima odgovarajuca polja u bazi (ime, lokaciju, broj soba ....) prema kojima se moze vrsiti search i advanced search.

E sad, klijent zeli da samostalno, kroz CMS, po potrebi doda dodatna polja (karakteristike) property-ja koji ce kasnije takodje uci u opcije pretrage.

Ne znam da li je to uopste moguce. Trenutno nemam ideju kako bih to resio. Mozda neko od vas moze da mi pomogne

pozdrav
Vanja
[ kelja @ 06.05.2008. 16:47 ] @
Hm, mnogo varijabli, moglo bi to, pretpostavljam, ali je zaheb...
(varijable- tip polja, ime, vrsta pretrage...)

Da ti ipak probas da dogovoris sa klijentom spisak mogucih karakteristika, i da napravis bazu koja ce sadrzati sva moguca polja/karakteristike, cija bi default vrednost bila, recimo, ''0'' ako su nesikoriscena, pa ih ne bi izlistavao/vrsio pretragu kroz njih u tom slucaju, a ako su iskoriscena onda radis i ispis i pretragu...

A on u admin panelu moze recimo da cekira koje ce opcije biti ukljucene i za koje imanje/kucu?

Mislim, nisu valjda ta imanja tako specificna da se ne bi mogao napraviti neki konacni spisak karakteristika?

Ne znam da li sam pomogao, ali valjda nije naskodilo...

[ mb_sa @ 06.05.2008. 19:02 ] @
Ako sam te dobro shvatio, mislim da je tako nesto slicno rješeno u OSCommerce e-shopu. Radi se o opciji Products Attributes, pa pogledaj u administraciji kako je to kod njih rješeno (jako je konfuzno rješeno, ali se moze to bolje uraditi), a onda pogledaj i strukturu tabela (to je on sto tebi treba). Konkretno kod njih je to recimo: imas proizvod, a onda imas osobine za njega (boja, militraza i slicno) i imas opcije za pojedine osobine (boja: crna, crvena ..., militraza: 30, 60, 90 ml, ...). Sa ovim mozes postici da svaki proizvod moze imati razlicite osobine i opcije. Recimo za parfeme koristis militraze, a za majice ponudis boje i velicine ...
[ agvozden @ 07.05.2008. 08:31 ] @
Ja koristim custom fields na foru cross fields-a - nesto slicno kako to radi ms access.
onda u bazu smestam samo polja koja su popunjena.

pretraga se radi sa join tabela, ali ovo moze biti problem ukoliko se ima vise stotina hiljada zapisa. u takvim bazama ne radim pretragu po tim poljima, barem ne na nacin sa direktnim sql upitom nad ovim tabelama vec pomocu tabela sa indeksiranjem kljucnih reci...
[ dakipro @ 07.05.2008. 08:42 ] @
Aleksandre, moze li jos malo infoa kako to radis na "foru cross fields-a" ?
Sa dodatnom tabelom sa poljima ili...?
[ agvozden @ 08.05.2008. 08:16 ] @
radi se sa dodatnom tabelom:

Code:
CREATE TABLE `bgs_ads_custom` (
  `ads_id` int(9) unsigned NOT NULL,
  `name` varchar(20) NOT NULL,
  `value` varchar(255) default NULL,
  KEY `ads_id` (`ads_id`,`name`)
) ENGINE=MyISAM;


uradim upit i rezultate smestam u asocijativni niz
Code:
$this->custom[$row['name']] = $row['value'];


vrednost je uvek tekst polje (255), pa je to malo nezgodno za pretragu kod velikih tabela. Ali ovo koristim uglavnom za dodatna, deskriptivna polja koja se nece koristiti u direktnoj pretrazi. Ukoliko je potrebno i njih pretrazivati onda je potrebna tabela sa kljucnim recima...
[ dakipro @ 08.05.2008. 08:33 ] @
Ok, hvala. Kontao sam da tako i radi, al reko aj da pitam, mozda ima nesto sto mi nije palo napamet.
Sta mislis da li bi mozda pomoglo/zakomplikovalo ako bi naziv polja drzao u posebnoj tabeli, a same vrednosti u posebnoj? mislim, smanjila bi se redundanca, ali bi verovatno opale performanse zbog dodavanja jos jedne tabele i novog joinovanja prilikom pretrage?
Mada, mozda bi pretraga isla i malo brze, jer bi onda tvoja tabela bila

Code:

CREATE TABLE `bgs_ads_custom` (
  `ads_id` int(9) unsigned NOT NULL,
  `fk_name_id` int(11) NOT NULL,
  `value` varchar(255) default NULL,
  KEY `ads_id` (`ads_id`,`fk_name_id`)
) ENGINE=MyISAM;


pa bi samo trazio po poljima where fk_name_id = xx AND value= yy ?
Imam ja ovo vec ovako odradjeno, sta vise, imam cak i var_value, bol_values, int_value, txt_value kao dodatno prosirenje koje mi omogucava da cuvam druge tipove podataka u dodatnoj tabeli sa stvarnom vrednostima. Onda ova tvoja tabel izgleda:

Code:

CREATE TABLE `bgs_ads_custom` (
  `ads_id` int(9) unsigned NOT NULL,
  `fk_name_id` varchar(20) NOT NULL,
  `var_value` varchar(255) default NULL,
  `bol_value` tinyint(1) default NULL,
  `int_value` int(11) default NULL,
  `txt_value` text default NULL,
  KEY `ads_id` (`ads_id`,`fk_name_id`)
) ENGINE=MyISAM;


Trenutno sam u fazi debele reorganizacije koda, pa hocu da ga maximalno optimizujem, a nisam previse jak sa mysql-om.
Znaci, da li je optimizovanije drzati nazive polja u jednoj tabeli a stvarne vrednosti po itemu u drugoj?
Takodje da li drzanje 4 tipova polja u jednom redu utice na performanse, jer su uvek druga 3 polja prazna?
Ako je ovaj slucaj ok, kako bi isla pretraga ondak po ovako organizovanim dodatnim poljima?
Mozda bih mogao i da postavim novu temu, ko zna...
Vidim da se ovo cesto postavlja kao pitanje, pa da svi to razradimo i testiramo jednom za svagda, da ubuduce ljudi znaju kako (se) ovo radi.
[ sheik @ 08.05.2008. 10:10 ] @
Moram da priznam da mi nije bas najjasnije ovo resenje. :)

Citat:
pretraga se radi sa join tabela, ali ovo moze biti problem ukoliko se ima vise stotina hiljada zapisa. u takvim bazama ne radim pretragu po tim poljima, barem ne na nacin sa direktnim sql upitom nad ovim tabelama vec pomocu tabela sa indeksiranjem kljucnih reci...


U pitanju je tabela u kojoj se ocekuje oko 1000 - 2000 zapisa.
Ne stojim bas najbolje sa MySQL-om pa molim za dodatno objasnjenje, kako napraviti pretragu baze po dodatnim poljima?