djoka_l: Rešenja za ove nedoumice zavise isključivo od načina na koje želiš da koristiš podatke.
Recimo, normalno bi bilo da za decimal koristiš double ako će se te vrednosti koristiti za obračune, na primer obračun kamate ili slično.
Međutim, ako je u pitanju samo učitavanje i prikazivanje podataka koje dobiješ upitima iz baze, možeš da koristiš stringove. Shvatam da je nezgodno to što kada radiš sa double tipom, mogu da se generišu greške zaokruživanja, ali to ne opravdava gubitak na brzini u komplikovanim izračunavanjima ukoliko umesto native double tipa, koji je podržan kroz FPU, koristiš neku klasu koja može da emulira decimal tip.
Oko druge dileme, rešenje se, opet, nameće kroz način upotrebe podataka. Jasno je da se normalna forma narušava ako, recimo, u tabeli faktura držiš ukupan iznos fakture, a u stavkama fakture pored količine i jedinične cene držiš i krajnju cenu (možemo zamisliti da tu imaš i polje za procenat popusta, pa onda iznos popusta i slično), ali to mnogo olakšava upite i formiranje izveštaja.
Još jedan primer narušavanja normalne forme bi bilo da držiš datum fakture u fakturi i datum fakture u stavci fakture, jer ćeš često morati da nađeš stavke fakture po opsegu datuma, a ako ubaciš takvu redundantnost, nećeš morati da radiš JOIN sa fakturom.
U slučaju akademskog projekta, to bi ti bilo zamereno. Ako je baza pre svega namenjena za transaction processing (OLTP) redundantosti, takođe, nisu preterano poželjne. Međutim za OLAP ovakve redundantnosti su OBAVEZNE. Kako će tvoja realna baza da se koristi za obe potrebe, najbolje je da svesno prekršiš pravila normalizacije i uvedeš redundantnosti, kako bi sebi olakšao život i ubrzao rad, s tmi da aplikacija mora da vodi strogo računa da se konzistentnost ne naruši.