|
02. 09. 2011. | #1 |
profesionalac
Professional
Datum učlanjenja: 30.08.2010
Poruke: 201
Hvala: 10
640 "Hvala" u 14 poruka
|
baza za online prodavnicu
Pozdrav svima. Pravim neku bazu za online prodavnicu racunara i treba mi savet oko organizacije iste. Evo o cemu se radi:
Treba pamtiti podatke komponentama i konfiguracijama komponenti koje prodavnica ima. Naravno administrator aplikacije mora da ima opciju da sve to menja (dodaje nove komponente i konfiguracije, brise, menja brojno stanje komponenti - standardica). Treba omoguciti i online narudzbu, tj da korisnik moze sam da napravi sebi konfiguraciju izborom komponenti. To je uglavnom najbitniji deo baze, ne racunajuci registraciju korisnika, definisanje administratora, ovlascenja sta ko moze da vidi itd. E sad, interesuje me ovaj dio oko komponenti, konfiguracija i narudzbi. Da li je zgodnije da sve komponente smestam u jednu tabelu ili da ih razvrstavam (npr posebno ploce, posebno procesore itd) ali u tom slucaju dobijam vise tabela. Ako bi ih stavio u jednu tabelu onda bi mogao da dodam jos jedno polje gde bi mogao da indetifikujem nekim parametrom da li su to ploce da li su procesori... zanima me sta je zgodnije i sta ce praviti manje problema u daljem radu. Nema potrebe da jos detaljisem, mislim da je svima jasno o cemu se radi. Hvala unapred svima ! |
02. 09. 2011. | #2 |
majstor
Wrote a book
|
1. Zasto izmisljas toplu vodu? Ukoliko pravis nesto konkretno, najbojlej e koristiti gotova rjesenja (e-commerce), ako hoces uciti - onda je razlog opravdan.
2. Zamisli da imas 100.000 razlicitih kategorija proizvoda (sto nije nemoguce u nekoj obicnoj prodavnici) .. koliko ces tabela u tom slucaju imati? Kakva ces im imena davati? Kako ces ih naci?... Jednom rijecju - ne radi se to tako. Znam da tebe buni to sto razlicite kategorije proizvoda imaju razlicite karakteristike, ali to se rjesava promjenjivim (opcionim) atributima koji su vezani za odradjene grupe / vrste proizvoda.
__________________
|
02. 09. 2011. | #3 |
profesionalac
Professional
Datum učlanjenja: 30.08.2010
Poruke: 201
Hvala: 10
640 "Hvala" u 14 poruka
|
Pa ucim, nista gotova resenja.
Pa kakve veze ima sto imam 100000 artikala ako imam, sto ti kazes, mogucnot da izvrsim kategorizaciju proizvoda (tastature, misevi, hdd, monitori). Koliko shvatam, ti predlazes da sve komponente budu u jednoj tabeli koja ce imati jedno polje "kategorije" pa ako se javi da imam 100 razlicitih monitora oni ce biti u tabeli pod kategorijom "monitori" i time sam na dalje resio problem sa manipulacijom (brisanje, promenu brojnog stanja u magacinu, ponudu korisniku da izabere odredjenu komponentu iz odredjene kategorije itd) ?!? |
02. 09. 2011. | #4 |
Ivan Dilber
Sir Write-a-Lot
|
imas tabele proizvodi, kategorije i veznu tabelu proiz_kateg koja ima samo polja proizvod_id i kategorija_id (posto je obicno pretpostavka da jedan proizvod moze da bude u vise kategorija, ako to nije potrebno onda mozes i bez ove tabele). Kategrije imaju polje parent_id, preko koga moze da se pravi hijerarhija tipa maticne_ploce -> intel -> i7 (a istovremeno ti ta ploca spada u recimo kategoriju Asus)
To je jednostavan deo, ono sto je komplikovanije su atributi za proizvode, posto nemaju iste osobine maticna ploca i tastatura, znaci treba da imas polja koja su pretraziva, a razlikuju se za svaku kategoriju proizvoda. Zato su za takve stvari bolje no-sql baze, recimo MongoDB je fenomenalan za takve poslove
__________________
Leadership is the art of getting people to want to do what you know must be done. Poslednja izmena od ivanhoe : 02. 09. 2011. u 17:03. |
"Hvala" ivanhoe za poruku: |
02. 09. 2011. | #5 |
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
|
02. 09. 2011. | #6 | |
profesionalac
Professional
Datum učlanjenja: 30.08.2010
Poruke: 201
Hvala: 10
640 "Hvala" u 14 poruka
|
Citat:
|
|
03. 09. 2011. | #7 |
profesionalac
Qualified
Datum učlanjenja: 23.06.2005
Poruke: 196
Hvala: 35
35 "Hvala" u 30 poruka
|
Ono što tebe zanima je verovatno EAV model (Entity-attribute-value model), pa potraži na Googlu. EAV ti daje fleksibilnost u opisu proizvoda različitim atributima, ali ima svoju cenu u pogledu brzine. Ako želiš prodavnicu opšte namene onda možda treba razmišljati o ovakvom rešenju, u suprotnom potraži način da izbegneš ovaj model.
|
03. 09. 2011. | #8 |
profesionalac
Professional
Datum učlanjenja: 30.08.2010
Poruke: 201
Hvala: 10
640 "Hvala" u 14 poruka
|
Evo, od prilike koliko sam shvatio za ovaj deo oko proizvoda, kategorija i narudzbe bi trebao da izgleda ovako. Samo jos nesto da razjasnimo, pod kategorijama se, u ovom slucaju,valjda podrazumevaju monitori,tastature,memorije itd, ako je to tako onda bi relacioni model licio na nesto ovako:
Kôd:
Proizvodi (idProizvoda, nazivProizvoda) Kategorije (idKategorije, nazivKategorije) Proizvodi_Kategorije (idProizvoda,idKategorije) Narudzba (idNarudzbe,idProizvoda,idKategorije) Kôd:
Proizvodi (idProizvoda, nazivProizvoda, idKategorije) Kategorije (idKategorije, nazivKategorije) Narudzba (idNarudzbe,idProizvoda,idKategorije) Poslednja izmena od slavkan : 03. 09. 2011. u 15:56. |
03. 09. 2011. | #9 | |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Da, to ti je već napisao ivanhoe:
Citat:
Što se tiče karakteristika proizvoda koji zavise od kategorije, pogledaj ovo što je preporučio dacha:
__________________
blog |
|
05. 09. 2011. | #10 |
Dejan Katašić
Wrote a book
Datum učlanjenja: 10.06.2005
Lokacija: Novi Sad
Poruke: 1.017
Hvala: 129
86 "Hvala" u 43 poruka
|
Nekako mi se čini da ti ove tabele za Narudžbe i Konfiguracije ne stoje baš. Na primeru konfiguracije imaćeš bar jednu njenu karakteristiku, ako ne drugo onda naziv, uz koji ti ide idKonfiguracije, dok tabela koju si predstavio bi valjalo da nosi ime Konfiguracije_Proizvodi (više prema više opet...
|
|
|