Radim jedan sajt za firmu koja prodaje gume i treba da napravim bazu podataka za unos i citanje guma. Ako je neko radio slican sajt ili bi imao ideju kako najlakse napraviti bazu za ovo, bio bih mu zahvalan na pomoci. Baza kod mene izgleda ovako
u bazi imam tabelu modeli, a u njoj sledece redove:
id
naziv (naziv modela gume npr. Pilot sport)
proizvodjac (Michelin)
opis (Ljetni pneumatik…)
slika (Pilot_sport.jpg)
akcija (da ili ne u zavisnosti da li zelim staviti gumu na akciju)
dimenzija (215/65)
precnik (R14)
index_br (H)
index_opt
vpc (200)
mpc (210)
Posto za jedan model gume postoji vise dimenzija, kako bi bilo najlakse napraviti bazu?
Ja sam mislio ovako
id
naziv (naziv modela gume npr. Pilot sport)
proizvodjac (Michelin)
opis (Ljetni pneumatik…)
slika (Pilot_sport.jpg)
akcija (da ili ne u zavisnosti da li zelim staviti gumu na akciju)
dimenzija1
dimenzija2
dimenzija3
dimenzija4
dimenzija5
precnik1
precnik2
precnik3
precnik4
precnik5
itd. za sve ostale redove
ali ovako treba dugo vremena zato sto mi treba 30 dimenzija, 30 akcija itd…
riješi to sa više tablica napraviš tablicu dimenzije i pucaš nutra id što ti je vanjski ključ, sad koliko toga ima ne znam, trebao bi vidjeti cijelu tablicu, ali ne loše riješenje bi možda bilo i da dimenzije spremaš odvojene nekim znakom
npr ;dimenzija1;dimenzija2;dimenzija3;…
pa bi opet dosta jednostavno dobio van gume s dimenzijama (LIKE “;%”);
uglavnom ne znam što sve imaš i trebaš pa ne mogu dati kompletni odgovor…
Ovako bi ja to riješio, na brzinu pa vjerovatno ima prostora za nadogradnju i ispravke, a nadam se da će se i trnac oglasiti kao jedan od malo većih znalaca na tom polju.
table Lager
lager_id
proizvodjac_id
model_id
dimenzija_id
promjer_id
vpc
mpc
stanje
Eto to bih ja ovako na brzinu tako napravio. Cilj kod izrade ovakovih programa i aplikacija je u tome da ti kasnije bude što lakše nadograditi i održavati aplikaciju, stranicu, trpanjem sve u jednu tablicu izrađuješ riješenje koje je “drži vodu dok majstori odu”.
Prema gore opisanom modelu svaki podatak je u svojoj tablici. A svakom podatku moižeš pristupiti preko jednostavnih i malo manje jednostavnijih SQL upita.
No kako reće nadam se da će se trnac oglasiti i toplo se nadam da će se kritički osvrnuti i na moje riješenje.
Eto dok sam ja pisao ti si nešto postao. Ali svejedno pogledaj ovaj primjer.
Ja bi se radije drzao manje normalizirane baze, bez FK-ova, da se ne rade joinovi kod upita. Ovo je cisto sa stanovista brzine. Ako ce sajt biti kompleksniji, mozda bi bilo to dobro uzeti u obzir.
U tablicu Modeli (to je u stvari matični podatak ARTIKL) treba staviti atribute dimenzija i promjer
Time se ukida tablica Modeli_Dimenzije_Promjeri
U tablicu Akcije treba staviti dva datumska polja da se zna od kada do kada je artikl na akciji i bilo bi dobro staviti koliki je akcijski popust.
Znači, tablica Akcije dobija polja datum_pocetak i datum_zavrsetak i rabat. Fućkaš akciju ako nema podatka koliki je popust.
Tablicu Lager bi rasturio i ostavio polja:
model_id
vpc
mpc
stanje
Tablica Lager se može proširiti atributom skladišta.
Pitanje za hotcoding-a: Treba li podatak mjesec/godina proizvodnje?
Ja nebih ni počeo dok nemam definiran konkretan zadatak…, ah da, danas.
Na ovom poslu me jedna strana firma totalno izvozala.
Blic po sječanju - lanci za snijeg, akcije, montaže ( s ugradnjom ili bez ) , konstantni popust za stalne kupce ( kad ovdje krenu kombinacije sa akcijama, jedni mogu na akciju, drugi ne jer već imaju dobre kondicije )
Vidjet češ kasnije ako nastaviš, mali milijun kombinacija… i sve ti dodaju na kapaljku
Sličice naravno u gif-u transparentno da se nevidi podloga…
Zar nije bolje odmah imati normaliziranu i dobro organiziranu bazu?
Što se tiće brzine, ako se poslože indexi, optimiziraju upiti, tablice i sama baza, onda nebi trebalo biti velike vidljive razlike u brzini izvođenja, a osim toga postoje viewsi i stored procedure, cachiranje podataka itd. itd.
A sve je to lakše kasnije nadodati nego redizajnirati bazu.
[quote=“CreatifCode”]Ne možeš to napraviti jer se onda stvara redundancija u tablici Modeli. Onda ćeš imati npr:
Model 1 - 15" - 205/55
Model 1 - 15" - 215/55
Model 1 - 15" - 225/45
Model 1 - 17" - 205/55
Model 1 - 17" - 215/55
Model 1 - 17" - 225/45
Model 2 - 18" - 205/55
Model 2 - 18" - 215/55
Model 2 - 18" - 225/45
Ah zaboravih reći da se s ostatkom manje više slažem.[/quote]
Kakva redundancija?
Od ovoga što si naveo, svaka stavka ima svoju šifru jer su to sve zasebni artikli.
I sada umjesto Model 1, Model 2,… stavimo prave nazive dobiješ npr. ovo …
Svaka kombinacija ima svoju šifru.
To sve proizlazi iz jedne sasvim obične činjenice koja kaže da svaka dimenzija ima svoju cijenu i shodno tome se vodi stanje za svaku dimenziju posebno.
Autogume nisu npr. majice gdje je boja majice ili veličina sporedan atribut i trgovci ne vode zalihiu po svakoj veličini nego vode zalihu za tu i tu majicu jer ta majica ima istu cijenu bez obzira na boju i veličinu.
akcija_rabat, vpc, mpc i stanje bi trebala biti polja tipa decimal
Ostalo je koliko vidim OK. Reducirao si broj tablica tako što si sirovi podatak širina-visina-promjer stavio svako u svoje polje… OK. Mada bi bilo dobro da staviš neku kontrolu kako bi spriječio tipfelere koji znatno utječu na smisao.
ali mi ne radi, ako bi neko mogao da pomogne!!!???
potrebno mi je da udruzim tabelu modeli sa tabelom lager i da izvucem sve podatke iz njih da bi ih mogao koristiti u html tabeli za prikaz modela
Po meni je lager_mpc bespotrebno polje, jer se ionako izračunava kao lager_vpc +PDV. Također i lager_stanje. Zašto ga ne računaš kao “svi ulazi” - “svi izlazi”?
Možda zbog arhive? ako se promjeni pdv cijena u prošlosti neće štimat…
Naravno može se to riješiti i sa još jednom tablicom pdv pa unutra polja vrijednost, od, do, ali u ovom slučaju možda previše kompliciranja…
