-
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.
|
| Vreme je GMT +2. Trenutno vreme je 12:46. |
|
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.
