Citat:
bluesman:
Da ne ulazim u polemiku, ovo je vrlo kontradiktorno. Kao reply na tezu "vazno je snalazenje - samo da radi" ti stavljas "da, ko ne plati na mostu - placa na cupriji".
To je bas ono sto ja hocu da ti kazem: ko ne projektuje od pocetka kako treba, vec budzi samo da radi, kasnije dodje u situaciju da mu se visestruko vrati tih par desetina minuta koje je ustedeo "budzeci" od pocetka.
Hm, pa ovo sto si rekao se u opstem slucaju svodi na ono sto sam ja rekao: ko ne plati na mostu, platice na cupriji. :)
Citat:
BTW, ovo nije 1-m nego m-m relacija...
Dobro, lupiio sam. Vadicu se na sitne sate :)
Citat:
StRiPy:
Kakva cetiri lookup polja?
Ako covek kaze da jedan prozivod moze da bude u najvise cetiri kategorije onda je njegovo resenje da u jedan slog uvede cetiri polja kojima se pravi veza ka kategorijama upotrebljivo. Nisam mislio da treba da objasnjavam sta mislim po lookup polje.... al dobro
Citat:
Pri projektovanju baze, odnosno tabela, uvijek se treba voditi racuna o fleksibilnosti doticne strukture za zeljenu aplikaciju. Pod tim se podrazumijeva izmjena aplikacije, a samim time i strukture baze, koja bi se morala izvesti na sto laksi i brzi nacin, a da opet bude efikasno i optimizovano. Pozeljno je izvrsiti sto vise stepena normalizacije, a minimalno 1NF.
Zasto da se ogranicavas u vezi bilo cega, pa tako i broja lookup-a tablica ili polja ?
Teorija isto tako kaze da ne treba insitirati na postovanju NF ako to moze da zakoplikuje aplikaciju i utice na performanse. Stavise, nije redak slucaj da se normalne forme namerno narusavaju, jer se time brze dolazi do podataka. Teorije normalnih formi uopste nje iskljuciva i zasniva se na preporukama pravila kojih se treba drzati ali ne po svaku cenu. U praksi se najcesce ide do 3NF, jer preko toga stvari umeju da postanu nepotrebno komplikovane.
Ja ne kazem da je ovaj konkretno takav (cak se ispostavilo da je upravo napravljena greska u startu sto nije postovan opsti slucaj i koriscena m-n veza, sto sam ja u prethodnoj poruci vrlo jasno rekao) ali postoje slucajevi, sretao sam ih u paksi de je u samom zadatku bilo iskljucivo ogranicavano da se ne radi o m-n vec o m-c vezi gde je c konstantan broj, bez ikakve mogucnosti da se to u buducnosti menja.
Citat:
Ti pravis (u ovom slucaju) web interfejs na osnovu potreba doticne aplikacije, a samim time i projektovane baze, a ne pravis bazu na osnovu web interfejsa. Prema tome, sto bolje i jednostavnije napravis bazu, lakse ce ti biti napraviti i web interfejs.
Uh... ponavljas ono sto sam ja vec rekao i to kao argument protiv necega sto sam rekao govoreci o mogucim IZUZECIMA.
Da se razumemo, pricamo o istom i slazemo se kada je teorija u pitanju i mislim da je to ocigledno.
Ja govorim o izuzecima koje teorija takodje postuje samim tim sto dozvoljava da se od pravila odstupi kada se proceni da ce se time dobiti na kvalitetu resenja. Radi se o tome da se prilikom projektovanja sve uzima u obzir pa i buduca aplikacija koja ce da radi na modelu.
Isto koliko sam apsolutno protiv toga da se ne postuju pravila da bi se na precac napravila aplikacija koja radi, isto tako sam protiv da se iskljucivo drzi teroije i da se nastoji da se postuju sva pravila, po cenu da se aplikacija u krajnjoj implementaciji nepotrebno zakomplikuje (a vidjao sam i takvih resenja). Kljucna rec je optimalno resenje.
Kada je web u pitanju, korisnicki interfejs ima znacajnije mesto u procesu projektovanja baze u odnosu na klasicne desktop aplikacije i to samo iz jednog razloga: web interfejs je po definiciji znatno slabijih mogucnosti i samim tim predstavlja ogranicavajuci faktor.
Registrovani: 5 ( vjova, Miroslav Cvejić, flighter_022, bojanum, daca80 )
Re: mysql nekoliko kategorija jednog proizvoda