Nové výhodné předplatné namísto kreditů je tu! Více informací. Upravili jsme také naše provozní podmínky.
NOVINKA: Staň se datovým analytikem a získej jistotu práce, lepší plat a nové kariérní možnosti. Více informací:
Avatar
shaman
Člen
Avatar
shaman:13.11.2015 15:53

Mam otazku na komunitu: Ukladam si v databaze data a vkladam vzdy novy riadok, pretoze potrebujem mat aj predosle verzie.
Neviem sa rozhodnut ktory sposob zistovania posledneho zaznamu je lepsi.

Moznost 1: Kazdy riadok ma stlpec verzia, kde sa integer cislo zvysuje o 1. Riadok s poslednou verziou je aktualna verzia.

Moznost 2: Kazdy riadok ma stlpec timestamp, kde je timestamp. Riadok s poslednym timestampom je aktualna verzia

Viete mi vysvetlit ktoru moznost by ste pouzili a preco?

Editováno
Odpovědět
13.11.2015 15:53
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
TomasGlawaty
Člen
Avatar
Odpovídá na shaman
TomasGlawaty:13.11.2015 16:40

Taky tohle budu řešit a přemýšlel jsem nad tím.

Napadla mě ještě jedna možnost:
v tabulce bude sloupec např. 'original', ve kterém bude ID toho úplně půdovního záznamu.
a pak to budeš tahat takto:

SELECT * FROM article WHERE article.original = 1755 ORDER BY article.id DESC LIMIT 1;

vytáhneš jeden záznam, který má jako absolutního 'rodiče' (sloupec original ) záznam s ID např. 1755, seřazeno podle ID sestupně - poslední verze.

Jinak z uvedených možností bych asi zvolil spíše 2. možnost. Příjde mi jednodušší nastavit defaultní hodnotu sloupci na CURRENT_TIMESTAMP , než vytahovat nějaký počet atd. je to takhle vlastně automatizováno :)

Ale kdyžtak počkej až se vyjadří někdo další ... :)

 
Nahoru Odpovědět
13.11.2015 16:40
Avatar
shaman
Člen
Avatar
Odpovídá na TomasGlawaty
shaman:3.12.2015 14:42

Vdaka za tip. Rozmyslam nad tym ze tych zaznamov tam pojde strasne vela a obcas aj velmi casto. To znamena ze v niektorych sekundach sa tam moze dostat aj viacero zmien jedneho zaznamu. V takom pripade by som mal viac zaznamov s rovnakym timestampom v stlpci timestamp a uz by som neveel urcit ktory je posledny. Preto si myslim ze prva moznost je asi lepsia.

Tvoje riesenie je tiez super a hodi sa do nejakeho jednoducheho CMS alebo tak. Tvoje riesenie nema vedomost o tom ktory zaznam je posledny. Predpokladas ze posledny je ten s poslednym id ale to nemusi byt pravda ak mas viac read a write nodes, mozes precitat staru informaciu ktora este nie je propagovana v DB pooli.

Napr ak by si riesil system prevodov v banke, tak by si chcel aktualizovat poslednu verziu stavu uctu a nie jej posledny zaznam v DB.

Este pockam ci sa vyjadri niekto iny. Ak nie, tak ta oznacim ako najlepsie riesenie.

Nahoru Odpovědět
3.12.2015 14:42
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
hitzoR
Člen
Avatar
hitzoR:3.12.2015 14:51

Je vůbec nutné nějaké data tahle verzovat? Takový návrh se mi moc nezdá.. Třeba pokud vezmu v potaz ten bankovní účet, tak přece není třeba jeho stav takhle "verzovat", ale pouze zpětně dopočítávat jeho stav podle provedených transakcí. Takhle bys měl v databázi vpodstatě redudantní data, což je většinou špatně.

 
Nahoru Odpovědět
3.12.2015 14:51
Avatar
shaman
Člen
Avatar
Odpovídá na hitzoR
shaman:3.12.2015 15:12

No dajme tomu ze zakaznik si vyziada bankovy vypis za posledny mesiac. Na nom nebude len posledny/aktualny zaznam(zostatok) ale vsetky zaznamy.

Transakcie verzovane nemam takze nemam ako spetne prepocitat co sa vtedy stalo. Problem je ze parametre transakcii sa casom tiez menia, napr cena za chleba je 15 korun dnes ale vcera bola len 12. Takze spetne si to neviem vypocitat.

Ktore data povazujes za redundantne?

Nahoru Odpovědět
3.12.2015 15:12
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
hitzoR
Člen
Avatar
hitzoR:3.12.2015 15:24

No v případě, že bych si ukládal transakce (včetně hodnoty transakce v té době, tzn. v tvojem příkladu 12 korun místo současných 15ti), tak platí, že zůstatek k určitému datu můžeš získat tak, že vezmeš současný zůstatek a přičteš k němu všechny proběhlé transakce. Tohle je hodnota, kterou jednoduše spočítáš a nemusíš ji ukládat zvlášť.

Navíc si nemyslím, že by časová náročnost takového výpočtu byla nějak podstatně vyšší než obyčejného selectu a pokud nemáš aplikaci s desetitisícema dotazama za sekundu, tak je zbytečné to takhle optimalizovat.

 
Nahoru Odpovědět
3.12.2015 15:24
Avatar
shaman
Člen
Avatar
Odpovídá na hitzoR
shaman:3.12.2015 15:46

Transakcie su dost zlozite, su tam rozne akcie, zlavy a nedaju sa spatne vypocitat aj kvoli malemu nahodnemu cislu. Uzivatelov je strasne vela a transakcii je este ovela viacej a vypocitavat pre kazdeho uzivatela stav uctu k zaciatku vekov by istotne bolo narocne. Pravdepodobne by bolo vhodne verziovat aj transakcie.

Netrap sa s rozhodnutim co je zbytocne optimalizovat ani aka je casova narocnost vypoctu - to rozhodnem ja. Pytal som sa na najlepsi model na verzovanie dat v big data systemoch.

Nahoru Odpovědět
3.12.2015 15:46
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
hitzoR
Člen
Avatar
hitzoR:3.12.2015 16:13

Nemusíš nic zpětně vypočítávat u transakcí, tam si jen uložíš její hodnotu. Pokud fakt vyloženě trváš na tom si ukládat minulé stavy účtu, tak bych to udělal jednoduše pomocí druhé tabulky a triggeru. V hlavní tabulce máš současný stav. Při jakékoliv změně se spustí trigger, který ti vezme starou hodnotu a uloží do vedlejší tabulky, kde si to budeš ukládat podle timestampu (PK by měl stačit id účtu + timestamp s přesností na milisekundy).

Ale stejně si myslím, že tohle není úplně správná cesta (ikdyž nevidím celou strukturu databáze), uživatel se síce dozví, jaké měl změny na účtu, ale nedozví se, kolik přesně za konkrétní transakci zaplatil/získal, když nastanou dvě a více transakcí najednou (pokud sem to dobře pochopil, tak transakce ukládáš, ale neukládáš hodnotu, takže když je pouze jedna, dá se to ze změny stavu jednoduše vyčíst, ale pokud je jich více, tak už ne).

 
Nahoru Odpovědět
3.12.2015 16:13
Avatar
shaman
Člen
Avatar
Odpovídá na hitzoR
shaman:3.12.2015 17:09

Ano, toto je navrh s ktorym momentalne pracujem.
Mam kolekciu v ktorej su aktualne stavy a mam druhu kolekciu, v ktorej je historia danych dokumentov. Druha kolekcia odkazuje na hlavnu kolekciu cez primary id a cez verziu. Vdaka tomuto rozdeleniu ma kolekcia s aktualnymi dokumentami o miliony zaznamov menej a hladanie je rychlejsie.

Mam tam aj timestamp ale ten nepouzivam pre pripad ze by niekto manipuloval datami. Verzie su lepsie, lebo vies presne povedat ci chyba nejaky dokument z kolekcia alebo je tam nejaky dokument ulozeny dvakrat.

V pripade ze by som potreboval transakcie, tak z rozdielov stavov medzi jednotlivymi dokumentami si viem vypocitat deltu zmeny.

Toto je zatial to najlepsie, na co som prisiel aj ja. Len ma zaujimalo ci vie niekto este lepsie riesenie verzovania.

Nahoru Odpovědět
3.12.2015 17:09
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 9 zpráv z 9.