Jedan artikal u više kategorija

[Dušan Dželebdžić]

Pišem skript za jednu on-line prodavnicu, pa sam naišao na sledeću mozgalicu:

Do sada sam se sretao samo sa slučajevima kada jedan artikal pripada jednoj kategoriji kataloga, i pripadnost kategoriji sam određivao tako što je tabela sa artiklima imala i polje za ID kategorije kojoj artikal pripada. Međutim, sad sam došao u situaciju gde isti artikal može da se pojavljuje u nekoliko različitih kategorija.

Ono što mi prvo pada na pamet je da napravim odvojenu tabelu sa dva polja - id i id_kategorije, pa da je onda kombinujem sa glavnom tabelom. Ima li boljih rešenja?

[jablan]

Ne, koliko je meni poznato.

[misk0]

Ono što mi prvo pada na pamet je da napravim odvojenu tabelu sa dva polja - id i id_kategorije, pa da je onda kombinujem sa glavnom tabelom. Ima li boljih rešenja?

To je i meni palo na pamet. Osim ako nemas determinisan broj kategorija, recimo 2-3 maximalno onda ti se isplati da dodas jos 2 polja u tabelu artikala, buduci da sifra kategorije nije duza od recimo 5 karaktera nece zauzimati bog-zna sta prostora i ako bude prazna.

[Ilija Studen]

Neki PHP hakeran iz Ukrajine bi stavio category_id polje kao VARCHAR i u njega stavio IDjeve kategroija odvojene unapred definisanim separatorom. Ali mi nismo ni hakerani, a nismo ni iz Ukrajine. A i ne potpisujemo se sa alex.

Sorry za gunđanje, ovo je bilo po istinitom događaju. Još bi bilo dobro da je samo na jednom mestu, ali čovek je realizovao sve m:n veze na ovaj način

[zextra]

Jos jedan glas za glue table, kao sredstvo za resavanje many2many relacije.

[MorenoArdohain]

Neki su to radili sa serialize :)

[artur_dent]

Kao što si i mislio dodatna tabela je najbolji način za to. Nemoj izmišljati mlaku vodu kada savršeno nema potrebe za tako nečim.

[dinke]

Koliko znam Moreno je radio neku drugu varijantu (ako se ne varam int ili bigint polje gde je svaka vrednost za odredjenu kategoriju jedan bit u broju), koju smo testirali protiv "standardne" varijante sa m:n odnosom, i ispostavilo se nakon benchmark-a da je prva varijanta znatno brza (doduse, benchmark obavljen na mysql-u na windows desktop makini).


Moreno moze vise o tome, ne secam se preterano detalja :)

[MorenoArdohain]

Ah da, trebalo mi je neko ultrabrzo resenje, posto je bilo u pitanju potencijalno veliki broj istovremenih mysql upita (problem sa lockovanjem), da ne duzim sad..

Primer, 4 kategorije se mogu predstaviti binarno:
1000, 0100, 0010, 0001 (decimalno: 8, 4, 2, 1)

Ako neko izabere prvu i trecu kategoriju, to je 1010 (dec: 10)
Naravno, samo decimalni broj se smesta u polje

A svi znamo da je upit nad jednom tabelom brzi od rada nad obe :)

[jablan]

To jeste jedno od mogućih rešenja, ali ima par mana:

Ograničen broj kategorija
Nemogućnost korišćenja referencijalnog integriteta (šta bude kad obrišeš kategoriju?)
U opštem slučaju, nisam siguran ni da je rešenje brže: kad koristiš bitove i imaš bitwise operatore u WHERE uslovu, indeks na tom polju ti ne vredi ništa, dok upit koji koristi odgovarajuće indeksiranu međutabelu može da bude prilično dobro optimizovan.

[MorenoArdohain]

^ delimicno se slazem, inace, imao sam max 15 kategorija, i svi su bili fiksni (nisu se mogli editovati, brisati i sl).

Sto se tice stavke 3, ne koriste se bit operatori u upitu, vec se pretraga radi po decimalnom broju..
Konkretno je u PHP-u preracunata decimalna vrednost, pa se radilo nesto kao WHERE category=15;

Inace, slazem se da je za njegov slucaj najbolje resenje sa 2 tabele.

[Dušan Dželebdžić]

Ukupan broj kategorija je neodređen, baš kao i količina kategorija kojima jedan artikal može pripadati. Pre par sati nisam bio siguran da je ovo najbolje rešenje, ali sad ste me ohrabrili :)

Sada ni meni ne radi quick reply

[misk0]

Sada ni meni ne radi quick reply

Bitno je da ti radi query :)

[jablan]

Sto se tice stavke 3, ne koriste se bit operatori u upitu, vec se pretraga radi po decimalnom broju..
Konkretno je u PHP-u preracunata decimalna vrednost, pa se radilo nesto kao WHERE category=15;
Ovo je baš specifičan slučaj, jer upiti obično idu u formi "daj mi sve objekte koji spadaju u kategorije 3 i 5" - gde indeks ne pomaže, a ne u formi "daj mi sve objekte koji spadaju samo u kategorije 3 i 5" - gde pomaže.

Da se razumemo, nemam ništa protiv vašeg modela, samo hoću da istaknem sve potencijalne zamke u radu s njim. ;)

[MorenoArdohain]

Edit: obrisao sam moj deo posta, nisam dobro procitao sta je jablan hteo da kaze, sorry
Inace, mislim da sam kasnije modifikovao resenje da koristi i bit operator bas za slucajeve kakve je jablan naveo, ali nisam behcmarkovao izmene. Cim se vratim na taj projekat, izmericu brzinu.

ddz, samo nastavi :)

[Pedja]

ddz, tako kako si zamislio je skolski i ispravno je.
Ideje sa precicama takodje nekada mogu da se pokazu dobre. Pored ovoga sa bitovima mozes prsoto da naprvic jedan varchar u koji ces da upisujes oznake kategoriaj kojima artikal pripada a da svaka oznaka bude jedno slovo engleske abecede. Tako ces imati nesto vise oznaka nego u binarnom sistemu a prinicp je slican.

Sve zavisi od konkretnog nacina upotrebe. Tvoj je najfleksibilniji i najbolje ce podrzati svakojake kombinacije. Binarni i ovaj "slovni" ima jednu sigurnu prednost sto je lakse napraviti interfejs za unos podataka (moze se recimo svesti na checkbox-ove ili listu u kojoj se radi multiple select), a moze se poakzati i efikasniji i iance.

Ne zaboravi nedavni eksperiment da se umesto JOIN-a za lookup koristi array sa prethodno ucitanim vrednostima i rucna pretraga po njemu, gde se ispostavilo da je ovo resenej sa nizom znatno efikasnije. ako znas sta tacno treba da se uradi i kontrolises stvar, moze da se dogodi da precica radi bolje iako nije bas "po skolski".

Napravi eksperiment, izgenerisi testne podatke i probaj oba pristupa.

[zextra]

Nekada (tj najcesce) je bolje uraditi po skolski, iako bi se (neznatno?) dobilo na brzini koriscenjem alternativnih resenja. Ako nista, a ono zato sto svako ziv zna kako many2many relacije funkcionisu, uz pomoc dodatne tabele, pa neko ko eventualno bude upgradeovao projekat nece morati mnogo da se razmislja zasto je nesto tako kako jeste. Nije redak slucaj da ni autor nema pojma zasto je nesto tako kako jeste, nakon godinu dana...

Ja stvarno ne znam ljudi sta vama ne radi? Sticajem okolnosti, sajt sam gledao iz ff 1.5.0.4 win, 1.5.0.5 win, 1.5.0.3 linux i svugde mi rade obe opcije..

[Dušan Dželebdžić]

I meni je radilo iz ff 1.5.0.5/win, a sad ne radi... A ako uspem da postujem onda opet radi

[dee]

@ddz

moze pomoci:
http://adria.fesb.hr/~vticinov/Baze1.doc


Ne zaboravi nedavni eksperiment da se umesto JOIN-a za lookup koristi array sa prethodno ucitanim vrednostima i rucna pretraga po njemu, gde se ispostavilo da je ovo resenej sa nizom znatno efikasnije. ako znas sta tacno treba da se uradi i kontrolises stvar, moze da se dogodi da precica radi bolje iako nije bas "po skolski".


ispricavam se ako je offtopic, ali mozes li malo detaljnije? o kakvom eksperimentu se radi?

[Pedja]

Evo ovde teme sa experimentom: http://www.devprotalk.com/showthread.php?t=798

[dee]

hvala :)