23.12.2013 11:35
1
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


mesicaffiladsenselinky
leden100020001000
unor400030002000


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.
23.12.2013 11:51
2
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í :-)
23.12.2013 11:52
3
Ř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í.
23.12.2013 12:09
4
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.
23.12.2013 12:10
5
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.
23.12.2013 12:55
6
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.
23.12.2013 13:14
7
Jsem pro neukládání.
23.12.2013 14:30
8
urcite nie, toto nema riesit db ale aplikacia.
23.12.2013 14:32
9
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.
23.12.2013 16:42
10
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
24.12.2013 21:55
11
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...