Je nějaká knihovna / rámec pro Undo / Redo změny řádků v databázi?

hlasů
2

Může být můj titul, není jasné. Dívám se na nějakou kontrolu verzí na databázové tabulky, stejně jako podvracení dělá na souborech, jako wiki dělá.

Chci sledovat změny protokolu. Chci extrahovat a spustit diff opačně. (Vrátit zpět jako svn sloučit -r 101: 100). I potřebovat indexovány vyhledávání na historii.

Četl jsem „ návrhový vzor pro vracení Engine “, ale to souvisí s „vzory“. Jsou tam něco, co bych mohl znovu použít, aniž by znovu vynalézat kolo?

EDIT: Například transakce bankovních účtů. Mám sloupec „vyváženost“ (a další) aktualizován v tabulce. uživatel najde chybu tím, že ho 10 dní později, a on bude chtít zrušit / vrácení konkrétní transakci, aniž by se změnila ostatní.

Jak mohu udělat to elegantně v aplikační úrovni?

Položena 09/12/2008 v 15:08
zdroj uživatelem
V jiných jazycích...                            


7 odpovědí

hlasů
2

Dalo by se použít postup revize pro každý záznam, který chcete sledovat. To by znamenalo zachovat řádek v tabulce pro každou revizi záznamu. Záznamy budou svázané dohromady společnou ‚ID‘ a mohl by být dotazovány na ‚Status Revision‘ (např Získejte nejnovější „Schváleno“ záznamu).

V aplikaci vrstvě, můžete zvládnout tyto záznamy individuálně a v případě potřeby, jak dlouho budete zaznamenávat všechny potřebné informace vrátit do dřívějšího stavu.

[ID] [Revision Date] [Revision Status] [Modified By] [Balance]
1     1-1-2008         Expired           User1         $100
1     1-2-2008         Expired           User2         $200
2     1-2-2008         Approved          User3         $300
1     1-3-2008         Approved          User1         $250
Odpovězeno 09/12/2008 v 16:40
zdroj uživatelem

hlasů
2

Martin Fowler se vztahuje na téma do vzorů pro věci, které se mění s časem . Statické vzory a ne skutečný rámec, ale on je uvedena ukázka dat a jak ji používat.

Odpovězeno 09/12/2008 v 16:19
zdroj uživatelem

hlasů
1

Pedantský bod. Váš příklad bankovní účet by neměla dostat přes auditorem / regulátorem.

Jakékoliv chybné údaje v účtu by měl být tam odešel do záznamu. Stejná a opačná korekce transakce by být aplikován na účtu. Ve skutečnosti vrácení zpět na původní transakce, ale zanechává velmi zjevné stopy původní chyby a její korekce.

Odpovězeno 09/12/2008 v 16:05
zdroj uživatelem

hlasů
0

Nejsem si vědom určitého vzoru, když jsem postavil plné undo / auditu historie před použitím spouští a rowversions.

Existuje několik aplikací pro MS SQL, které umožňují probírat protokolů a vidět skutečné změny.

Použil jsem jeden volal Log Navigator zpět s MS SQL 2000, který používal, aby mi dovolil vrátit specifickou historickou operaci - nemohu ho najít hned ačkoli.

http://www.lumigent.com a http://www.apexsql.com dělat nástroje pro prohlížení protokolů, ale nemyslím si, že buď můžete je vrátit zpět.

Myslím, že nejlepší způsob, jak to udělat, je napsat svůj aplikace s ohledem na tuto skutečnost - která máte pár dobrých návrhů zde již, jak to udělat.

Odpovězeno 10/12/2008 v 11:20
zdroj uživatelem

hlasů
0

Na základě různých připomínek bázi možným řešením problému by bylo, aby se „datum účinnosti“ tabulky.

V podstatě přidáte platné-z aktuální a platné k datu sloupců každém stole.

„Aktuální“ záznam by měl mít vždy valid_to_date o „2999-12-31“ nebo nějakým arbiteraly vysokou hodnotu. Když se změní hodnota změníte „platný-to-date“ na aktuální datum a vložit nový řádek s platným-z-datu dneška a platné k datu „2999-12-31“ zkopírovat všechny sloupy ze starého řadě, pokud nebyly změněny.

Můžete vytvořit zobrazení s "select all-sloupce-kromě-valid-xx-data ze stolu, kde platí aktuální = '2999-12-31'"

Která umožní, aby všechny své stávající dotazy pracovat beze změny.

Jedná se o velmi časté tecnique ve skladových prostředích datových a pro věc, jako směnné kurzy, kde je datum účinnosti je důležitá.

Logika undo by mělo být zřejmé.

Odpovězeno 10/12/2008 v 11:07
zdroj uživatelem

hlasů
0

Já bych jít s bi-temporální návrh databáze, která by vám všechny údaje potřebné k provedení a vrácení zpět, ať už to znamená, že vložením více řádků nebo jednoduše odstraněním pozdější úpravy.

K dispozici je slušné množství jemností k takovému návrhu databáze, ale je tu velmi dobrá kniha na toto téma:

Vyvolávací doba orientovaných databázových aplikací v SQL Richard T. Snodgrass

k dispozici ke stažení zde:

http://www.cs.arizona.edu/people/rts/tdbbook.pdf

Použití transakce databáze by být špatný nápad, protože zámky by to vytvořilo v databázi - v podstatě databázové transakce by měly být co nejkratší.

Cokoliv v aplikační vrstvě, pokud to má nějakou vytrvalost mechanismus sám, nepřežije restart aplikace (i když to nemusí být požadavkem).

Odpovězeno 09/12/2008 v 18:02
zdroj uživatelem

hlasů
0

Na vaše připomínky James Anderson založen, musel bych uživatelské rozhraní psát novou vložku při zrušení transakce. To by vložení nového záznamu do tabulky, která měla stejné hodnoty jako zrušená transakce s výjimkou hodnoty by bylo záporné číslo namísto kladné číslo. Máte-li konstrukce, která zahrnuje něco definovat účel transakce, řekl bych, aby to říci zruší a rekordní počet transakcí se ruší.

Odpovězeno 09/12/2008 v 17:05
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more