传统版本的理解
1、复制数据
传统意义上的版本，针对整体数据进行复制多份数据，每个用户根据自己的数据进行相关的编辑操作，最后统一的进行合并操作。
2、锁定数据
另一个版本的概念就是多用户编辑同一份数据，但是针对某一条记录来说采取“锁定—编辑—释放”的方式进行的，这就制约了长事物编辑的概念。
ArcGIS版本的理解
ArcGIS版本与传统关系数据库的版本（复制、锁定）有着本质的区别，可以把ArcGIS版本理解为对数据库的快照，版本代表着一种状态，它只记录编辑变化的数据，所谓变化的数据就存储在相关的变化表中，没有变化的数据在物理上只存储一次，ArcGIS版本可以为多个用户创建属于该用户自己的版本，每个用户在对应的版本上可以进行长时间的编辑也就长事物的编辑，而且他们之间互不影响，因为各自编辑的数据都存储在变化表中。在用户编辑事物完毕后，可以将对应版本协调相关的父版本，如果有冲突解决相关冲突，协调完毕后可以提交到上一版本了。
所有的子版本都可以利用相关的操作过程进行提交，将所有子版本的相关编辑信息都提交到最终的DEFAULT版本，也就完成了一个多版本、多用户并发协作一个项目。
使用场景：数据入库
一般入库都会直接录入到目标数据库中，特别是入增加数据时（表中原来100条，再导入100条情形），如果出现断电或者死机等情况，就会录入部分数据，而且已经对目标数据库的相关数据进行了改变，这样剩下的数据也不知道该从哪条导入，这就给我们的实际工作带来了很大不便，但是我们可以利用ArcGIS版本原理来解决相关问题。我们可以在原有版本基础上创建一个子版本，在子版本进行数据入库，在我们没有进行协调提交之前，是不会真正改变目标数据库的，导入数据其实是在变化的表进行存储，这样就是出现非正常的死机或断电也不至于对我们的目标数据进行改变。
ArcGIS版本的工作流程
1.注册版本
如果数据导入到ArcSDE中，那么在SDE用户下的table_registry表中会有相关的信息进行注册，系统就会产生一个注册ID。当该要素类（FeatureClass）注册为版本时，系统就会自动创建A<注册ID>、D<注册ID>两个存储数据变化的表。
A表会继承FeatureClass同名表（base table）的所有字段和类型信息，而且会添加一个SDE_STATE_ID的整型字段，主要记录增加数据的一个状态ID。它是串联版本原理的关键值，版本就是通过该值来记录相关的编辑状态的。
所有表注册后，D表的结构都是一样的。DELETED_AT是代表编辑删除的状态，SDE_STATE_ID是代表删除某个要素对应的状态。如果SDE_STATE_ID=0代表删除的是BASE表的数据，如果SDE_STATE_ID>0代表是删除的编辑增加的数据。
table_registry表中的数据
| registration_id |
database_name |
table_name |
rowid_column |
description |
… |
| 7 |
SDER |
JSL |
OBJECTID |
NULL |
… |
| 8 |
SDER |
SHL |
OBJECTID |
NULL |
… |
| 9 |
SDER |
BASE_TABLE |
OBJECTID |
NULL |
… |
A9表中的数据
| OBJECTID |
SHAPE |
SDE_STATE_ID |
… |
| 2 |
1 |
2 |
… |
| 4 |
2 |
4 |
… |
| 5 |
3 |
7 |
… |
| 6 |
4 |
7 |
… |
| 7 |
5 |
7 |
… |
| 8 |
6 |
11 |
… |
A7表中的数据
| OBJECTID |
SHAPE |
SDE_STATE_ID |
… |
| 1 |
1 |
8 |
… |
| 2 |
2 |
14 |
… |
| 3 |
3 |
14 |
… |
| 4 |
4 |
15 |
|
| 5 |
5 |
16 |
|
D9表中的数据
| SDE_STATE_ID |
SDE_DELETES_ROW_ID |
DELETE_AT |
| 7 |
6 |
9 |
| 7 |
7 |
10 |
| 11 |
8 |
12 |
states表中的数据
| state_id |
owner |
creation_time |
closing_time |
parent_state_id |
lineage_name |
| 0 |
sde |
… |
… |
0 |
0 |
| 2 |
SDE |
… |
… |
0 |
2 |
| 4 |
SDE |
… |
… |
2 |
2 |
| 7 |
SDE |
… |
… |
4 |
2 |
| 8 |
SDE |
… |
… |
7 |
2 |
| 9 |
SDE |
… |
… |
8 |
2 |
| 10 |
SDE |
… |
… |
9 |
2 |
| 11 |
SDE |
… |
… |
10 |
2 |
| 12 |
SDE |
… |
… |
11 |
2 |
| 14 |
SDE |
… |
… |
12 |
2 |
| 15 |
SDE |
… |
… |
12 |
15 |
| 16 |
SDE |
… |
… |
15 |
15 |
states（编辑状态表）
主要存储所有的编辑状态，包含编辑开始时间和结束时间，上一个编辑状态等信息。
mvtables_modified表中的数据
| state_id |
registration_id |
| 2 |
9 |
| 4 |
9 |
| 7 |
9 |
| 8 |
7 |
| 9 |
9 |
| 10 |
9 |
| 11 |
9 |
| 12 |
9 |
| 14 |
7 |
| 15 |
7 |
| 16 |
7 |
mvtables_modified（多表多版本状态表）
主要存储所有参与注册版本编辑的图层以及相关多版本的有效编辑状态信息。
2.创建子版本
versions表中的数据
| name |
owner |
version_id |
state_id |
parent_name |
parent_version_id |
… |
| DEFAULT |
sde |
1 |
12 |
NULL |
NULL |
… |
| NewVeision01 |
SDE |
2 |
14 |
DEFAULT |
1 |
… |
| NewVersion02 |
SDE |
3 |
16 |
DEFAULT |
1 |
… |
versions（版本表）
主要是记录数据的版本信息以及各个版本对应的最新编辑状态等信息。
status：默认为1，表明该版本正在进行版本事务状态。
state_id：获得最新的编辑状态ID。
state_lineages表中的数据
| lineage_name |
lineage_id |
lineage_name |
lineage_id |
| 0 |
0 |
15 |
0 |
| 2 |
0 |
15 |
2 |
| 2 |
2 |
15 |
4 |
| 2 |
4 |
15 |
7 |
| 2 |
7 |
15 |
8 |
| 2 |
8 |
15 |
9 |
| 2 |
9 |
15 |
10 |
| 2 |
10 |
15 |
11 |
| 2 |
11 |
15 |
12 |
| 2 |
12 |
15 |
15 |
| 2 |
14 |
15 |
16 |
state_lineages（编辑状态世系表）
主要存储针对多版本的相应版本对应的版本状态。
lineages_modified表中的数据
| lineage_name |
time_last_modified |
| -1 |
2015-04-17 16:24:39.000 |
| 2 |
2015-04-17 21:36:23.000 |
| 15 |
2015-04-17 21:55:27.000 |
3.编辑版本
进行版本编辑，相关的变化数据就会存储到相应的A表、D表中，并不会直接修改Base表的数据。
4.协调版本
概念：编辑版本、协调版本、子版本、父版本
协调版本就是在用户完成相关的编辑事务后，将自己的编辑版本（子版本）协调相关的父版本（把父版本协调到自己的版本上），主要是协调有没有冲突。
5.解决冲突
就冲突类型而言，具体有3种类型的冲突：
（1）编辑版本更新而协调版本也更新（UpdateAndUpdate）
（2）编辑版本更新而协调版本删除（UpdateAndDelete）
（3）编辑版本删除而协调版本更新（DeleteAndUpdate）
对于存在冲突的地物，它将存在3种不同的值：协调版本的值、编辑版本的值和编辑前版本的值。
6.提交版本
Post是将子版本的修改提交到父版本中去。
当数据加载进系统时，table_locks发生变化。
| sde_id |
registration_id |
lock_type |
| 20 |
7 |
S |
| 20 |
8 |
S |
| 20 |
9 |
S |
当数据加载进系统时，state_locks发生变化
| sde_id |
state_id |
autolock |
lock_type |
| 20 |
16 |
N |
S |
