In the enterprise database design, often encounter a demand, it is hoped the data before the operation preserved, can see what is before the operation data, what data after the operation. For this demand, we can use historical data to retain or use version to achieve.
In order to be able to keep historical data, the following program in versions of the design:
First, the version number
The version number is a common version of the design is to be increased in a version number field to retain historical data table above, this field may be DateTime type, it can be int type, every data manipulation, is to create a the new version, the version is only to rise, so only need to get a maximum version number, you can get the latest business data.
In addition to the version number can be used to retain historical data, there is a function to avoid concurrent editing. For example, we have an object A, the current version is 1, two users to simultaneously open the edit page of the object, the data changes. A new version of the first user to commit changes, this time the system ID and the version of the object query and found to modify the latest version of the data is 1, so successfully modified, saved the object A 2. This time user B also submit the changes. The ID system and version 1 query object, find the latest version of the data to be modified is 2, does not meet the requirements, so refused to modify the user B's. User interface B only refresh, get the latest version 2, and then modify it.
| ID | Single number | Money | version number |
| 1 | EXP123 | 100 | 1 |
In the case of the version number, the amount of documents to be modified to create a new version 2 version:
| ID | Single number | Money | version number |
| 1 | EXP123 | 100 | 1 |
| 2 | EXP123 | 120 | 2 |
Second, the use of force, failure time
The second way to save is to use historical data to indicate a failure time to take effect version. To increase the historical data record table "effective time" "dead time" two fields, two fields do not allow empty. For data just created, to take effect is to create the data time, dead time is 9999-12-31. Now these pieces of data has been modified, then we only need to set the current time on a version of the expiration time, while creating a new data, the effective time is the current time, time to failure is to 9999-12-31.
| ID | Single number | Money | Effective time | Failure time |
| 1 | EXP123 | 100 | 2013/9/1 15:30:00 | 9999/12/31 23:59:59 |
For example, above a document is created 2013-9-1 later modify that document in 2013-9-9 15:00:00, the amount created when saving revised to 120 from 100, the new data are as follows:
| ID | Single number | Money | Effective time | Failure time |
| 1 | EXP123 | 100 | 2013/9/1 15:30:00 | 2013/9/9 15:00:00 |
| 2 | EXP123 | 120 | 2013/9/9 15:00:00 | 9999/12/31 23:59:59 |
Use the force, after the expiration time, we can query the value of the data in the database at any time, just need time to be passed in the query, and then between the effective time and time to failure.
Both require before using a natural key to identify a particular service data. If we want to record the entity is no clear "single number", "Order Number" natural key kind of how to do? We can use the database primary key when creating data as a natural key.
| Employee ID | Full name | birthday | Business ID | version number |
| 1 | Joe Smith | 1984/12/29 | 1 | 1 |
For example, we have a staff table, record basic information about employees, when you create a data of the employee Joe Smith, No. 1, it can be business ID is also set to 1 in the ID database. Next, John's property changes, recorded a version, it will create a new version of its primary key "employee ID" will change, but the natural key "business ID" is always 1, will not change.
| Employee ID | Full name | birthday | Business ID | version number |
| 1 | Joe Smith | 1984/12/29 | 1 | 1 |
| 2 | Joe Smith | 1985/1/9 | 1 | 2 |
Using the previous two programs, though well capable of recording historical data, but each modification data will lead to a new generation version saved, so each version of ID is new, so there must be a natural key to identify an entity here two examples of "one-number" is its natural key. Change primary key such that all associated objects have to change, so as to form a chain reaction, so that each object is also associated to generate a new version. For example, we have orders system, there are orders table and Order Details tables. Now we have to modify the order to record the version history, so increasing the effective time and time effectiveness, and use the order number as the natural key. Now there is an order A, below 100 details, if you want the order to be modified, the one a breakdown of attributes to be modified, resulting in a change of the entire order, then we need to create a new order data lines, since the master key changes, so order details need to change, so 100 details need to create a new version, the new version of the order details, the "Order ID" pointing to the ID of the new version of the order data.
This design problem is caused by the Order Details table will speed expansion, if there is a 1000 order details, we just modify the attributes of the order itself does not modify the order details, can also cause this 1000 details do Copy, and then save . then what should we do? We can use the following approach:
1. Order Details establish a version field, a version of granularity down to the order details, rather than orders. Orders and order details do not exist at the database level foreign key relationships, there is only a foreign key relationship service level. That in order to increase the effective time schedule, other than the failure time, but also increase the "Order Number" in this field, the name of the table details which belong to the order of.
So we modified the order if the object is modified, the order details have not changed (such as change a bit the recipient information), you only need to generate a new row of data in the Orders table, Order Details Copy will not generate new data. If we are to a certain order details make changes (ratio adjusted unit price, quantity) then you only need to modify the piece orders for specific details to make changes without having to change all the details of the entire order.
After using this design, check orders and their details, you need to perform two tables for the entry into force of filtered failed time and get the details of the order number to get through, rather than pick up by order ID.
When version control granularity down to the order details, logic daemon will be more complicated. The user interface is operated in order object, the object after the order of the entire system will spread to modify the background, the background program needs to be compared for each line item, if you find a line item has been modified, it will generate a new version of the call orders details of the method.
2. Use a separate history table
This is another way to achieve historical record of version:
Third, use a separate history table
Use the history table is actually establish exactly Schema table (of course, you can also add more fields to record additional version history information), the table only keep historical versions of data. It's kind of like an archive logic, all historical versions we think should not be frequently accessed, all can be thrown into a separate table for the existing version of the entry into force, it remains in the original table, if the need to query the historical version, then from history table query.
Use a separate history table has the following benefits:
- The amount of data traffic history data table will not release records and expansion. Because historical data are recorded to another table, so the business data table only records copy of the data.
- Schema business data sheet does not need adjustment, additional version field. Because not Schema changes to the original data table, so do not change the logic of the original query. For an existing database design, while the addition of historical data logging easier.
- Can directly service data table update operation, does not generate new ID. Since the ID does not change, and so we need to be applied to natural key application logic.
When using the history table version is mainly to record history data method of operation (add, delete, modify) be modified so that each data operation, the first traces of the history table, and then perform data manipulation. The other is to query the historical version of the function to be modified, because the historical data in another table, so for the SQL is not the same. Of course, we can also create a historical version of the database, which holds all of the history table.
Original Address: https: //www.cnblogs.com/studyzy/p/3310266.htmlIn the enterprise database design, often encounter a demand, it is hoped the data before the operation preserved, can see what is before the operation data, what data after the operation. For this demand, we can use historical data to retain or use version to achieve.
In order to be able to keep historical data, the following program in versions of the design:
First, the version number
The version number is a common version of the design is to be increased in a version number field to retain historical data table above, this field may be DateTime type, it can be int type, every data manipulation, is to create a the new version, the version is only to rise, so only need to get a maximum version number, you can get the latest business data.
In addition to the version number can be used to retain historical data, there is a function to avoid concurrent editing. For example, we have an object A, the current version is 1, two users to simultaneously open the edit page of the object, the data changes. A new version of the first user to commit changes, this time the system ID and the version of the object query and found to modify the latest version of the data is 1, so successfully modified, saved the object A 2. This time user B also submit the changes. The ID system and version 1 query object, find the latest version of the data to be modified is 2, does not meet the requirements, so refused to modify the user B's. User interface B only refresh, get the latest version 2, and then modify it.
| ID | Single number | Money | version number |
| 1 | EXP123 | 100 | 1 |
在使用版本号的情况下，对单据的金额进行修改，修改后创建新的版本号2：
| ID | 单号 | 金额 | 版本号 |
| 1 | EXP123 | 100 | 1 |
| 2 | EXP123 | 120 | 2 |
二、使用生效、失效时间
保存历史数据的第二办法是使用生效失效时间来表示一个版本。要进行历史数据记录的表增加“生效时间”“失效时间”两个字段，两个字段不允许为空。对于刚创建的数据，生效时间是创建该数据的时间，失效时间是9999-12-31。现在对这条数据进行了修改，那么我们只需要将当前时间设置为上一个版本的失效时间，同时创建一条新数据，生效时间是当前时间，失效时间是9999-12-31即可。
| ID | 单号 | 金额 | 生效时间 | 失效时间 |
| 1 | EXP123 | 100 | 2013/9/1 15:30:00 | 9999/12/31 23:59:59 |
比如上面一条单据，是2013-9-1创建的，后来在2013-9-9 15:00:00对该单据进行修改，将金额从100修改为120，保存时创建的新数据如下：
| ID | 单号 | 金额 | 生效时间 | 失效时间 |
| 1 | EXP123 | 100 | 2013/9/1 15:30:00 | 2013/9/9 15:00:00 |
| 2 | EXP123 | 120 | 2013/9/9 15:00:00 | 9999/12/31 23:59:59 |
使用了生效、失效时间后，我们可以查询任意时刻数据库中数据的值，只需要把要查询的时刻传入，然后between 生效时间 and 失效时间即可。
使用前两种方案都需要一个业务主键来标识具体的一个业务数据。如果我们要记录的实体没有明确的“单号”、“订单号”这类的业务主键该怎么办？我们可以使用创建数据时的数据库主键作为业务主键。
| 员工ID | 姓名 | 生日 | 业务ID | 版本号 |
| 1 | 张三 | 1984/12/29 | 1 | 1 |
比如我们有个员工表，记录员工基本信息，在创建张三这个员工的数据时，其在数据库的ID为1，那么可以将其业务ID也设置为1。接下来对张三的属性进行更改，记录了版本，那么就会创建新的版本，其主键“员工ID”会变化，但是其业务主键“业务ID”始终是1，不会变化的。
| 员工ID | 姓名 | 生日 | 业务ID | 版本号 |
| 1 | 张三 | 1984/12/29 | 1 | 1 |
| 2 | 张三 | 1985/1/9 | 1 | 2 |
使用前面两个方案虽然能够很好的记录历史数据，但是每次修改数据都会导致新版本生成保存，所以每个版本的ID都是新的，所以必须有一个业务主键来标识一个实体，这里的两个例子“单号”就是其业务主键。主键的变动使得所有关联的对象都得变动，从而形成连锁效应，使得各个关联的对象也生成新的版本。比如我们有个订单系统，里面有订单表和订单明细表。现在我们要对订单的修改记录历史版本，所以增加了生效时间和实效时间，并使用订单号作为业务主键。现在有一个订单A，下面有100条明细，如果要对订单进行修改，将某一条明细的属性进行修改，从而导致整个订单的变化，那么我们就需要创建新的订单数据行，由于主键变动，所以订单明细都需要变动，所以100条明细都需要创建新的版本，新版本的订单明细中，“订单ID”指向了新的版本的订单数据的ID。
这样的设计造成的问题就是订单明细表会极速膨胀，如果一个订单有1000条明细，我们只是修改了订单本身的属性，并不修改订单明细，也会造成对这1000条明细做Copy，然后保存。那怎么办呢？我们可以使用以下办法：
1.对订单明细建立版本字段，将版本的粒度细化到订单明细，而不是订单。订单与订单明细不存在数据库级的外键关系，只存在业务级的外键关系。也就是说订单明细表中增加生效时间、失效时间之外，还需要增加“订单号”这个字段，用于表名该明细是属于哪个订单的。
我们这么修改后，如果订单对象进行了修改，订单明细没有修改（比如改了一下收件人信息），那么只需要在订单表中生成新的一行数据，订单明细不会Copy生成新的数据。如果我们对某一条订单明细进行了更改（比调整了单价、数量）那么只需要对具体修改的那条订单明细进行更改，而不需要对整个订单的所有明细进行更改。
使用这种设计后，查询订单及其明细，需要对两个表执行生效失效时间的过滤，而且明细的获取是通过订单号去取，而不是通过订单ID去取。
When version control granularity down to the order details, logic daemon will be more complicated. The user interface is operated in order object, the object after the order of the entire system will spread to modify the background, the background program needs to be compared for each line item, if you find a line item has been modified, it will generate a new version of the call orders details of the method.
2. Use a separate history table
This is another way to achieve historical record of version:
Third, use a separate history table
Use the history table is actually establish exactly Schema table (of course, you can also add more fields to record additional version history information), the table only keep historical versions of data. It's kind of like an archive logic, all historical versions we think should not be frequently accessed, all can be thrown into a separate table for the existing version of the entry into force, it remains in the original table, if the need to query the historical version, then from history table query.
Use a separate history table has the following benefits:
- The amount of data traffic history data table will not release records and expansion. Because historical data are recorded to another table, so the business data table only records copy of the data.
- Schema business data sheet does not need adjustment, additional version field. Because not Schema changes to the original data table, so do not change the logic of the original query. For an existing database design, while the addition of historical data logging easier.
- Can directly service data table update operation, does not generate new ID. Since the ID does not change, and so we need to be applied to natural key application logic.
When using the history table version is mainly to record history data method of operation (add, delete, modify) be modified so that each data operation, the first traces of the history table, and then perform data manipulation. The other is to query the historical version of the function to be modified, because the historical data in another table, so for the SQL is not the same. Of course, we can also create a historical version of the database, which holds all of the history table.
Original Address: https: //www.cnblogs.com/studyzy/p/3310266.html