Keeping page changes history. A bit like SO does for revisions

前端 未结 3 1827
隐瞒了意图╮
隐瞒了意图╮ 2021-01-02 06:24

I have a CMS system that stores data across tables like this:

Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+         


        
3条回答
  •  轻奢々
    轻奢々 (楼主)
    2021-01-02 06:59

    Hi am currently working on solution to similar problem, I am solving it by splitting my tables into two, a control table and a data table. The control table will contain a primary key and reference into the data table, the data table will contain auto increment revision key and the control table's primary key as a foreign key.

    taking your entries table as an example

    Entries Table
    +----+-------+------+--------+--------+
    | id | title | text | index1 | index2 |
    +----+-------+------+--------+--------+
    

    becomes

    entries             entries_data
    +----+----------+   +----------+----+--------+------+--------+--------+
    | id | revision |   | revision | id |  title | text | index1 | index2 |
    +----+----------+   +----------+----+--------+------+--------+--------+
    

    to query

    select * from entries join entries_data on entries.revision = entries_data.revision;
    

    instead of updating the entries_data table you use an insert statement and then update the entries table's revision with the new revision of the entries table.

    The advantage of this system is that you can move to different revisions simply by changing the revision property within the entries table. The disadvantage is you need to update your queries. I am currently integrating this into an ORM layer so the developers don't have worry about writing SQL anyway. Another idea I am toying with is for there to be a centralised revision table which all the data tables use. This would allow you to describe the state of the database with a single revision number, similar to how subversion revision numbers work.

提交回复
热议问题