tool or technology to assist in controlling database data

Asked

Viewed 160 times

1

I have a web application, that constantly the database receives data, the application is all tied to the database.

if a change is made can compromise the whole system, I wish I could return a point when necessary.

GIT is for file version control.

would have some tool or technology to assist in controlling the database data ?

  • 1
  • something like this, but not mysql versioning, but data status .

  • 1

    I got it, I thought it was the structure versioning, not the data

  • Are you talking about back up. That’s for me back up. You do back up data or uses a Seed for testing. In the most, again, back up.

  • 1

    I know there is back up, I want to know if there is something more practical to do the control of the data

  • Maybe something that goes closer is the functionality flashback oracle.

Show 1 more comment

2 answers

2


Starting with version 9i of the Oracle database, a concept called undo was introduced, in which you can recover deleted or changed data over a period of time. Example select * from clients as of timestamp systimestamp - interval '10' minute. I don’t know if it exists for mysql, I would have to search. This link explains this concept well.
http://laercioleo.blogspot.com.br/2009/06/oracle-comando-milagroso-como-recuperar.html

  • I came to find something like COMMIT and ROLLBACK but I didn’t understand if it fits yet

  • 1

    COMMIT and ROLLBACK are commands used within a transaction. Example you made a trial that ran multiple updates/exclusions/inclusions and at the time you committed an error if you call ROLLBACK, all actions performed within that transaction will be undone. The oracle UNDO concept works as if it were a versioning of the tables, but for a certain period of time.

1

There is no automatic solution for this, you have to create the versioning engine manually.

you can for example insert a field called VERSAO in the table and not allow update in the records, to update a record you create a new one with the incremented version number. Logically this will inflate your table, so you should be judicious when defining which tables of your system you will want to keep this revision history.

Another option is to create another table only to keep old versions of the record, for example you can have a CLIENTS table and a CLIENTES_HISTORY table, which has the same fields, plus a version number, revision date, user who made the change, etc. This process can be done via triggers to facilitate. When "edit" a record you must enter the current record in the revision table. When deleting a record you can make a cascading physical deletion ( delete in both tables) or make a logical deletion (mark the record as disabled).

All of this is laborious, but if your system needs log history for audit reasons, these are a few options. I recommend the second.

This topic has further discussions on the subject.

  • the problem is that the changes are not made by a script that I run, a user is using the application and that can make these changes, I do not have control of what has been changed and when.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.