Citat:
Getsbi:
Veoma redak slučaj. Takva polja se izbegavaju još u ranoj fazi modeliranja podataka jer narušavaju treću normalnu formu. Razlog je eventualna promena ulaznih činilaca izračuna što automatski usložnjava održavanje baze podataka i njenu konzistentnost dovodi u pitanje.
Stanje=Ulaz-Izlaz. Kod ispravke moraš da menjaš i ono što nebi morao. Ako si omašio unos datuma rođenja moraš da menjaš i polje starost. Jednostavno nema smisla računati nešto i upisivati u tabele kad možeš upitom da ga dobiješ trenutačno i prikažeš na formi ili izveštaju. Pogotovo pri današnjim brzinama procesora i SSD diskova.
[Ovu poruku je menjao Getsbi dana 14.11.2022. u 10:57 GMT+1]
Postoje slučajevi kada je zgodno imati izračunatu vrednost polja u bazi. Jedno je 3NF, drugo je realan problem.
Tebi, kao početniku, predlažem da pristupaš dizajnu baze "po knjizi". Tek kada budeš imao "u malom prstu" normalizaciju podataka, onda razmišljaj o narušavanju normalne forme.
Baza podataka se ne pravi samo zato da bude prekrasna, nego i da bude korisna. Kada god sam u bazi našao narušavanje normalne forme, bilo je to iz jako dobrog razloga.
Primer:
Radiš neke nabavke, pa imaš cenu robe koju kupuješ. Na tu robu ide PDV. Da li treba da držiš u bazi posebno cenu bez PDV, iznos PDV i zbir cene i PDV?
Teorija kaže da ne moraš, jer ukupnu cenu uvek možeš da izračunaš kao zbir. Međutim imaš zahtev biznisa da se napravi pretraga i izveštaj po ukupnoj ceni.
Oracle, recimo, podržava function based indekse. Možeš da napraviš index po cena+PDV i uvek kada radiš pretragu tipa where cena+PDV > 1000 Oracle koristi taj index.
Kada nemaš function based indekse, onda bi takva neka pretraga uradila full table scan.
Mnoge baze nemaju takvu mogućnost, pa bi bilo pametno dodati takvu kolonu.
Drugi primer:
Imaš naloge za kniženje i stavke naloga. Na nivou naloga držiš podatak o datumu knjiženja. Normalno je da se nalog knjiži tako da se sve ili ni jedna stavka proknjiže.
Da li onda treba držati datum knjiženja na nivou stavke? Teorija kaže ne, praksa kaže da. Vrlo često je potrebno praviti pretraživanje i izveštaje o finansijskim promenama po datumu knjiženja, a tom prilikom ni jedan drugi podatak iz naloga nije potreban, osim datuma knjiženja. Ako se držiš knjige, radiš join naloga iz stavke samo zbog jednog podatka iz naloga.
Dakle, kada se baza projektuje, ona se ne projektuje samo uzimajući u obzir zauzeće prostora i čuvanje podataka, nego i za pretrage i izveštavanja. Jednostavno, nekada se zažmuri na narušavanje knjiških pravila da bi se dobilo na brzini upita.