-
Programiranje
(
http://www.devprotalk.com/forumdisplay.php?f=23)
| Dušan Dželebdžić |
31. 07. 2006. 16:51 |
Jedan artikal u više kategorija
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 |
31. 07. 2006. 16:52 |
Ne, koliko je meni poznato.
|
| misk0 |
31. 07. 2006. 16:57 |
Citat:
Originalno napisao ddz
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 |
31. 07. 2006. 17:05 |
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 |
31. 07. 2006. 17:10 |
Jos jedan glas za glue table, kao sredstvo za resavanje many2many relacije.
|
| MorenoArdohain |
31. 07. 2006. 17:30 |
Neki su to radili sa serialize :)
|
| artur_dent |
31. 07. 2006. 17:54 |
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 |
31. 07. 2006. 18:24 |
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 |
31. 07. 2006. 18:33 |
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 |
31. 07. 2006. 19:58 |
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 |
31. 07. 2006. 20:12 |
^ 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ć |
31. 07. 2006. 21:52 |
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 :)
Off Topic: Sada ni meni ne radi quick reply |
| misk0 |
31. 07. 2006. 21:56 |
Citat:
Originalno napisao ddz
Off Topic: Sada ni meni ne radi quick reply
|
Bitno je da ti radi query :) |
| jablan |
31. 07. 2006. 21:56 |
Citat:
Originalno napisao MorenoArdohain
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 |
31. 07. 2006. 22:10 |
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 |
31. 07. 2006. 22:17 |
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 |
31. 07. 2006. 22:28 |
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...
Off Topic: 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ć |
31. 07. 2006. 23:11 |
Off Topic: I meni je radilo iz ff 1.5.0.5/win, a sad ne radi... A ako uspem da postujem onda opet radi |
@ddz
moze pomoci:
http://adria.fesb.hr/~vticinov/Baze1.doc
Citat:
Originalno napisao Pedja
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 |
02. 08. 2006. 07:35 |
|
| Vreme je GMT +2. Trenutno vreme je 08:48. |
|
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.
