Database versioning

Post on 18-Dec-2014

3,149 views 1 download

description

Describes how to givee MySQL databases the notion of time. Lets you roll back database tables to any point in time, consistently across tables and without affecting other users.

transcript

Johan Sölve@macsolve

http://re.solve.se

Relational databases

• Two dimensional

• Rows and columns

• Only know about NOW

• Has no concept of ”history”

What if we can add a

third dimension?

What if we can add the notion of

TIME

Data Versioning

Data Versioning

• ”Time Machine” for data

• Snapshot of any point in time

• Immediately and continously available

• No rollback or restore of database

• Demo:

http://johan.solve.se/dataversioning/

Data Versioning

• Consistent across tables

• Solution for MySQL

• Uses VIEW to access data

• Data access it transparent to the application

• Unique for each database session/visitor

Views

• Views are like search macros

• They are created as a saved SELECT statement

• Performs good if indexed properly

Data Versioning

• Each table is replaced by a ”data” table that maintains every version of each row/record

• Common ”version” table

• Points at current row in data table

• Keeps meta data about changes

• Each table is completed by a VIEW to

Never Change

• Most important:

• Never update or delete a row in the data table

• All changes add a new row in the data table

Time

Row 1Row 2Row 3Row 4Row 5

Table

Time

Row 1Row 2Row 3Row 4Row 5

Table

Table 2

Row 1Row 2Row 3Row 4

Database operations– CRUD

• SELECT from a view - just as usual

• INSERT creates a row in data table and verison table

• UPDATE updates a timestamp in the version table and creates a row in the data table and version table

• DELETE updates a timestamp in the version table

Database operations– CRUD

• SELECT – no change

• INSERT, UPDATE, DELETE handles specially

• Triggers and Stored procedures

• Or in the application’s database abstraction layer

INSERT

INSERT INTO version (guid, changedby_start) VALUES ("gweyufghkj", "JS");

INSERT INTO people_data (id_version, firstname, lastname) VALUES(LAST_INSERT_ID(), "Nisse", "Hult");

UPDATE

UPDATE version SET changedby_end="JS", dt_end=NOW() WHERE guid="gweyufghkj" AND dt_end="3000-01-01 00:00:00";

INSERT INTO version (guid, changedby_start) VALUES ("gweyufghkj", "JS");

DELETE

UPDATE version SET changedby_end="JS", dt_end=NOW() WHERE guid="gweyufghkj" AND dt_end="3000-01-01 00:00:00";

SELECT

SELECT * FROM people;

View

CREATE VIEW people AS

SELECT people_data.*, version.guid

FROM people_data

JOIN version ON

people_data.id_version=version.id

WHERE dt_start <= history()

AND dt_end > history();

Go Back in Time

SET @history="2010-02-22 10:00:00";

SELECT * FROM people;

Only affects this database session

Uses

• Content Management

• Definitions for dynamic forms

• Data entry must match form definition at any point in time

Considerations• Carefully evaluate for each table if it’s

relevant to include it in data versioning

Example:

• Permission settings

• What if the table structure changes?

• Performance

• Consider using emulated

Implementation

• Modified knop_database

• Methods for:

-> addrecord

-> saverecord

-> deleterecord

Read more

• Description:

http://re.solve.se/database-versioning

• Demo:

http://johan.solve.se/dataversioning/

Johan Sölve