Rozdil dvou hodnot, uložit X neuložit

Ahoj, představme si že mám databazi zisku, ktere se každý měsíc mění. A chci vedet rozdil oproti minulemu mesici. neco takoveho mám v dtb

mesic	affil	adsense	linky
leden	1000	2000	1000
unor	4000	3000	2000

atd. a ve frontedu chci videt neco jako

mesic	affil	adsense	linky
leden	1000	2000	1000
unor	4000 (+3000)	3000 (+1000)	2000 (+1000)

ukladate tyto udaje (tucne) taky do databaze nebo ne?

ulozeni
-narocne na vlozeni radku (nacteni minuleho, dopocitani, vlozeni)
+lip se to selectuje

neulozeni
+min narocne na vlozeni radku
- hur se to selectuje a musi se nacist vic radku coz tolik nevadi a vetsinou se minule radky stejne nacitaj.

Osobně bych to uložil, ve výsledku mi to přijde nejméně náročné - náročnost na vložení se projevuje jen jednou, pokud bych to chtěl řešit, na úrovni db, tak bych použil joiny při každém čtení, což je náročnější, řešení na úrovni aplikace vyžaduje načtení dalších dat, která mě aktuálně nazajímají a smyčka, co to bude zpracovávat bude o něco složitější (a kód tak může být meně pochopitelný).

Hardcore databázisti možná budou mít námitky, že je to proti normalizaci a ukládám redundantní data, ale za ten pořádek to myslím stojí :-)

Řekl bych, že by to byla v podstatě "duplicita".
Nejsem teda žádnej odborník na databáze, myslím ale, že podobný věci je lepší nedělat a ten rozdíl spočítat až při zobrazení.

Jsem pro neukládání. Když by jsi pak zpětně nějakej řádek upravil, musel by jsi upravovat i ty spočítané hodnoty.
Selectoval bych to pokaždé, případně zvolil vhodnou cache.

imho to duplicita není, ale záleží k čemu ty data mají být:
- pokud jen k zobrazení, pak by se o to měla postarat aplikační logika - to je nejsnažší řešení a v cyklu si vždy jen spočítáš výsledek
- pokud se nad tím mají provádět nějaké operace, pak to ukládej - to je složitější a časem se Ti to prostě rozjede (to je pravidlo), někde něco upravíš přímo v db a už to nebude sedět.

Nazdar.

Ja som riesil podobnu vec. Riesil som to pridanim stlpca do databazy. U mna vypocet tej hodnoty pri zobrazovani trva dlhsie a pri zobrazovani by to zbytocne spomalovalo. Ta hodnota u mna sa pocita len raz za den pri urcitej udalosti a potom sa len zobrazuje.

Dalsi sposob, ktory som tiez pouzil je pridanie do tabulky computed column - pocitany stlpec. Neviem ci ti to umoznuje databaza. Vypocit hodnoty stlpca by si ti v takom pripade posunul na uroven databazy a vypocitanu hodnoty by si len zobrazoval

---------- Příspěvek doplněn 23.12.2013 v 12:59 ----------

Původně odeslal James_Scott ↪

Jsem pro neukládání. Když by jsi pak zpětně nějakej řádek upravil, musel by jsi upravovat i ty spočítané hodnoty.
Selectoval bych to pokaždé, případně zvolil vhodnou cache.

Da sa napisat triger a starat sa o vypocet bude databaza. Takze na urovni aplikacnej logiky by nemusel niec riesit.

Jsem pro neukládání.

urcite nie, toto nema riesit db ale aplikacia.

Pro většinu scénářů jsem pro neukládání. Viz výše, navíc možná budeš chtít zobrazovat nárůsty ne jenom meziměsíčně, ale kvartálně, ročně,... a za chvíli by ses v tom zapastil.
Smysl by to mělo, pokud by spočítání bylo hodně náročné a výsledek by se mnohokrát zobrazoval. Anebo pokud by ta spočítaná čísla byla "svatá" a jakmile by se jednou vyreportovala, nesměla by se změnit, bez ohledu na vstupní data. Asi to není ani jedno.

data by se menit nemela, a kvartalni pocty a podobne pocitat taky ne - max graf s hodnotami za sebou.

taky se cim dal vic klanim k neukladni, ale ukladani mi prijde takovy cistejsi :( :D

Nam v škole profesor tĺkol do hlavy - čo sa dá dopocitat nech sa dopocitava, čo sa nedá nech sa uklada... Cize v tomto pripade ak nad tým neplanujes operácie a bude to vyslovene na výpis tak si to ries v aplikacnej logike nakoľko ti to nebude nijako zpomalovat kedze sa jedna o jednoduche spocitanie/ odcitanie predošlej hodnoty...