Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Spremanje izračuna u tablici

[es] :: Access :: Spremanje izračuna u tablici

[ Pregleda: 717 | Odgovora: 3 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Spremanje izračuna u tablici14.11.2022. u 00:41 - pre 16 meseci
Čitao sam o bazama podataka pa sam naletio na tekst gdje se navodi da izračune ne treba spremati u tablicama. Jedino spremite izračunatu vrijednost ako je izuzetno složena za izračunavanje, zahtijeva puno vremena izračuna i često se koristi.

Primjer navode da se dob osobe ne navodi u tablici nego se upisuje datum rođenja pa se dob izračunava na način da se od trenutne godine oduzme godina rođenja.

Čitao sam malo o temi 'magacina' pa je tamo rečeno da se stanje dobije kada se od izlaza oduzme ulaz.

Koliko je čest slučaj zapisivanja izračunatih podataka u tablici?

 
Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2828



+45 Profil

icon Re: Spremanje izračuna u tablici14.11.2022. u 07:47 - pre 16 meseci
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]
 
Odgovor na temu

BiloKoje
Beograd

Član broj: 40147
Poruke: 401



+4 Profil

icon Re: Spremanje izračuna u tablici25.11.2022. u 04:05 - pre 16 meseci

Od prvih koraka u Accessu držao sam se pravila da u tabelu ne unosim izračunate podatke, u svim knjigama koje sam pročitao to je jedan od osnovnih saveta, pravila, u tabelu se unose osnovni podaci, izračunavanje se radi u upitima.
Međutim, od verzije 2010 Access tabele imaju tip polja Calculated, vrednost polja se ažurira nako svake izmene ulaznih podataka, moglo bi se reći da donekle ubrzava rad, opet sve to se postiže i upitom, nisam baš tražio objašnjenja zašto je Microsoft promenio jedan pristup. Primenjivao sam, tu i tamo, u praksi i izračunata polja u tabeli, ne mogu reći ni da smeta ni da pomaže.

 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: Spremanje izračuna u tablici25.11.2022. u 10:29 - pre 16 meseci
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.
 
Odgovor na temu

[es] :: Access :: Spremanje izračuna u tablici

[ Pregleda: 717 | Odgovora: 3 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.