使用Hibernate进行分层数据版本控制的数据库设计是什么?

时间:2013-09-26 16:11:46

标签: java database hibernate postgresql database-design

我需要存储分层数据的更改历史记录。数据是一对多关系:设置实体具有许多属性。这是我的表格:

Setting
------------------------------
Id            INTEGER NOT NULL
CompanyId     INTEGER NOT NULL
Name          TEXT NOT NULL


SettingProperty
------------------------------
SettingId            INTEGER NOT NULL
PropertyName         TEXT NOT NULL

我正在使用Hibernate作为ORM,相应的Java实体看起来有点像

public class Setting {

    private int id;
    private int companyId;
    private String name;

    private Set<String> properties;
    // ....
}

现在,只要设置名称更改或属性添加到设置中,我就需要存储更改的完整历史记录。我还需要轻松查询给定时间点的历史设置。我考虑了多种不同的选择,即:

  1. 在'设置'表中添加'ChangeDate'列(告诉我们何时修改了给定的设置版本)和'CommonId'列(告诉我们哪些实体及时形成单个设置的历史记录 - 即如果是当名称更改时,新设置版本具有新名称和新ID,因此我们需要告知这只是相同设置的新版本)。这很简单,应该可以工作但是要查询最新的当前数据(即SELECT * FROM设置WHERE ChangeDate =(SELECT MAX(ChangeDate ...))
  2. 有一个只有Id的表,一个BLOB(用于保存整个序列化的Java设置对象)和一个ChangeDate。这样我只使用一个表就可以了,但是当我想在Setting对象中添加/删除某些东西时我遇到了大麻烦,因为我需要更新已保存的对象。
  3. 为上面的每个表创建一个单独的History表(具有相同的列和ChangeDate) - 这使得查询当前数据变得容易(只使用常规表),但是维护几个具有几乎相同模式的表是一些轻微的疼痛。
  4. 有任何建议或更好的想法吗?请记住,我正在使用Hibernate,因此并非所有SQL查询都可能。我的DB是PostgreSQL。

2 个答案:

答案 0 :(得分:1)

最终我们决定使用Hibernate Envers,因为它可以为我们工作

因此我们将使用它为我们生成的任何映射表:)

答案 1 :(得分:0)

我没有历史记录表的经验,但这可能会有所帮助:

首先,我建议您的友好邻居DBA审核您的数据库架构。 虽然我不是DBA,但这里有一些建议:

Setting
        settingID           long not null, primary key
        companyID           long not null, foreign key to Company table
        name                varchar(255) not null, unique

SettingProperty
        settingPropertyID   long not null, primary key
        settingID           long not null, foreign key to Setting table
        name                varchar(255) not null, unique

Company
        companyID           long not null, primary key
        name                varchar(255) not null, unique
        abbr                varchar(50), unique


Notes: 
       0: primary keys are always named with the table name followed by 'ID'.
       1: Table names begin with a capital letter
       2: column names begin with a lower case letter
       3: primary keys are to have no business meaning        
       4: primary and foreign keys are long and not int 
       to ensure the max value isn't likely to be reached.
       5: I suggest you consider calling your tables something 
       more meaningful than Setting and SettingProperty (assuming
       there is such a meaning).
       6: Consider adding company abbreviation to your Company 
       table (abbr), which can be null, but must be unique.
       7:Don't add columns to the database tables being audited
         with auditing information. They should be ignorant of the fact
         they are being audited.
       8: Use database triggers to update a history table when a record
         is updated, inserted, or deleted. Don't do it in Java.
       9: Search Google for 'store historical data in database triggers' or similar search
          on how to best create a history table.
         Example:
       https://www.google.com/#q=storing+historical+data+in+database+triggers&start=10
       10: There is a column with not null and unique, and another with nullable and unique.
         Some databases don't like nullable and unique (it treats more than one null in the 
         column as violating the unique rule).