Există vreo bibliotecă / cadru pentru undo / redo modificări de rânduri, în baza de date?

voturi
2

Poate fi titlul meu nu este clar. Caut un fel de control al versiunilor pe tabelele bazei de date, cum ar fi repunere în discuție face pe fișiere, cum ar fi wiki nu.

Vreau să urmărească modificările jurnal. Vreau să extragă și a alerga dif în sens invers. (Undo ca un svn îmbinare -r 101: 100). Am putea avea nevoie de o căutare indexate în istorie.

Am citit „ modelul de proiectare pentru Undo Engine “, dar este legat de „Mostrele“. Sunt ceva am putea reutiliza fără să reinventeze roata?

EDIT: De exemplu, tranzacțiile de cont bancar. Am coloana „echilibru“ (și altele) , actualizate în tabelul. un utilizator va găsi o greșeală de el 10 zile mai târziu, și el va dori să anuleze / derula înapoi tranzacția specifică, fără a schimba altele.

Cum pot face cu gratie in nivelul de aplicare?

Întrebat 09/12/2008 la 15:08
sursa de către utilizator
În alte limbi...                            


7 răspunsuri

voturi
1

punctul pedant. Exemplul tău cont bancar nu ar obține un auditor rămas singur / regulator.

Orice înregistrări eronate într-un cont ar trebui să fie lăsat acolo pentru înregistrare. O tranzacție opusă și egală de corecție ar fi aplicată contului. În efect de rulare înapoi tranzacția inițială, dar lăsând o urmă foarte evidentă a erorii inițiale și corectarea acesteia.

Publicat 09/12/2008 la 16:05
sursa de către utilizator

voturi
2

Martin Fowler acoperă subiectul în modele pentru lucruri care se schimba cu timpul . Încă modele și nu un cadru real , dar el prezintă exemple de date și cum să - l folosească.

Publicat 09/12/2008 la 16:19
sursa de către utilizator

voturi
2

Ai putea folosi o abordare de revizuire pentru fiecare înregistrare pe care doriți să urmărească. Acest lucru ar implica reținerea unui rând din tabelul pentru fiecare revizuire a unei înregistrări. Înregistrările vor fi legate împreună printr-un „ID“ Distribuit și ar putea fi interogate pe „Stare de revizuire“ (de exemplu Obtineti cel mai recent „Aprobat“ înregistrare).

La nivelul aplicației, puteți gestiona aceste înregistrări în mod individual și se rostogolească înapoi la o stare anterioară, dacă este necesar, atâta timp cât vă înregistra toate informațiile necesare.

[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
Publicat 09/12/2008 la 16:40
sursa de către utilizator

voturi
0

Bazat pe un comentariu la James Anderson, mi-ar fi interfața cu utilizatorul a scrie un nou insert la anularea unei tranzacții. Aceasta ar introduce un nou record în tabelul care au aceleași valori ca tranzacția anulate, cu excepția valorii ar fi un număr negativ în loc de un număr pozitiv. Dacă aveți o structură care include ceva pentru a defini scopul tranzacției, mi-ar face o spun anulat și numărul de înregistrare a tranzacției a fost de anulare.

Publicat 09/12/2008 la 17:05
sursa de către utilizator

voturi
0

Aș merge cu un design de baze de date bi-temporale, pe care le-ar da toate datele necesare pentru a efectua și revocați dacă acest lucru înseamnă mai multe rânduri inserarea sau ștergerea pur și simplu modificările ulterioare.

Există o valoare justă de subtilitate la un astfel de design bază de date, dar există sunt foarte bune carte pe această temă:

Dezvoltarea orientată către timp Aplicații baze de date în SQL de Richard T. Snodgrass

disponibil pentru descărcare aici:

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

Folosind o tranzacție de bază de date ar fi o idee rea, deoarece încuietorile ar crea în baza de date - în principiu, tranzacțiile de baze de date trebuie să fie cât mai scurtă posibil.

Orice în stratul de aplicare, cu excepția cazului în are un mecanism de persistență în sine, nu va supraviețui reporniri de aplicare (deși, care nu ar putea fi o cerință).

Publicat 09/12/2008 la 18:02
sursa de către utilizator

voturi
0

Pe baza diferitelor comentarii o posibilă soluție pentru problema ta ar fi de a face o „data intrării în vigoare“ de masă.

Basicly adăugați coloane valide-la-data și valide la zi la fiecare masă.

Înregistrarea „curentă“ ar trebui să aibă întotdeauna o valid_to_date de „2999-12-31“, sau o valoare arbiteraly ridicată. Atunci când o valoare se schimbă când modificați un rând nou „valabil la zi“ la data curentă și se introduce cu o validă-de la-data de astăzi și un pașaport valabil la data de „2999-12-31“, copiați toate coloane din rândul vechi în cazul în care nu au fost modificate.

Puteți crea vederi cu „selecta toate coloanele cu excepția-validă-xx-data de la masă unde valabil la data =«2999-12-31»“

Ceea ce va permite toate întrebările dvs. actuale să funcționeze neschimbat.

Acesta este un tecnique foarte frecvente în medii depozit de date și pentru lucru ca ratele de schimb în cazul în care data intrării în vigoare este important.

Logica Undo ar trebui să fie evident.

Publicat 10/12/2008 la 11:07
sursa de către utilizator

voturi
0

Nu sunt conștient de un model specific, cu toate că am înființat complete istorii undo / audit inainte de a folosi declanșatoare și rowversions.

Există o serie de aplicații pentru MS SQL care vă permit să traul prin jurnalele și a vedea modificările reale.

Am folosit unul numit Log Navigator înapoi cu MS SQL 2000 care a folosit pentru a lasa-mi anula o tranzacție istorică specifică - Nu pot să-l găsesc acum, totuși.

http://www.lumigent.com și http://www.apexsql.com face instrumente pentru vizualizarea jurnalele, dar nu cred că nici vă permite să le rostogolească înapoi.

Cred că cel mai bun mod de a face acest lucru este de a scrie o aplicatie cu acest lucru în minte - care aveți câteva sugestii bune aici deja cu privire la modul de a face.

Publicat 10/12/2008 la 11:20
sursa de către utilizator

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