版本情景
本主题将介绍版本化的应用，即如何将此技术应用于企业内部，同时还将介绍可用的版本配置。
各企业之间的工作流有很大差别。它们通常分为独立的阶段向前推进，并且每个阶段都需要分配一组不同的资源与业务规则。一般来说，整个流程中的每个阶段都表示一个独立的工作单元，如工作指令。要管理各个工作指令，可以创建单独的孤立版本并对其进行修改。当您对完成的工作感到满意后，可以将更改集成到已发布的数据库版本中。通过这种方式使用版本，您能够同时适应最基本和最复杂的工作流程。
您最可能采用的方案是同时编辑已发布的数据库（多个编辑人员修改 DEFAULT 版本），或者采用某些其他配置的组合。了解企业和业务需求并认清每种配置的优缺点，将有助于您选择最适合贵企业的配置。
出于简化和地理数据库管理考虑，建议的最佳做法是保持扁平版本树或让多个编辑者同时编辑 DEFAULT 版本。
同时编辑已发布的数据库
多个用户可以同时编辑同一版本，因此对于多个编辑人员来说，支持多用户编辑的最简单方法是直接编辑 DEFAULT 版本。
 |
随着各个编辑人员开始编辑 DEFAULT 版本，在编辑会话中将自动创建临时未命名版本。只有当前编辑人员才可以访问此临时版本。当编辑人员保存其工作内容或结束编辑会话后，临时版本中记录的更改将被提交到 DEFAULT 版本。
如果在您开始编辑后其他用户编辑了 DEFAULT 版本，则当您保存工作内容时，ArcGIS 会自动进行协调并提交更改。系统会通知您版本已被更改，必须重新保存以接受其他编辑人员所做的更改。启用“ArcMap 选项”对话框中的自动协调可以绕过此警告消息。无论是否绕过此消息，如果存在冲突，都必须使用冲突解决对话框解决冲突，之后才能成功保存编辑内容。
优点：
- 此策略对简单的数据库修改支持较好，因为用户无需创建新版本即可编辑数据。这在工作单元较小或不需要长期设计方案时非常适用。
- 如果不存在冲突，保存的编辑内容将直接提交到 DEFAULT 版本。
缺点：
- DEFAULT 版本不断变化并且易受意外修改或未授权修改的影响；因此，数据库管理员可能需要更频繁地创建数据库备份。
- 不支持长期事务或创建跨多个编辑会话的替代设计版本。
- 每个地理数据库在任何指定的时间都只能有一个协调操作处于活动状态。如果频繁出现来自各个编辑会话的协调与提交操作，编辑人员在保存其更改时可能需要等待活动的协调与提交过程结束。在大型多用户地理数据库中，最好避免多个用户协调并提交到公共版本的情况。协调与提交会以独占方式锁定版本；当版本锁定时，其他用户将无法完成任务。
- 由于所有协调操作都是自动执行的，此策略不支持批处理协调过程。在自动协调与提交主题中介绍了批处理协调操作。
多个项目
如果要管理多个项目或工作指令，您需要更加结构化的工作流管理方法。对于涉及多个编辑会话并持续数日、数周或数月的独立工作单元，可以在不影响 DEFAULT 版本的情况下对其进行维护。例如，这些独立的工作单元可以是高速公路改造方案、安装新电话服务或者正在进行的煤气管道维护项目。
 |
当启动某个工作指令或项目时，会创建一个 DEFAULT 版本的子版本。一个或多个编辑人员可以在此版本中工作，直到该工作指令或项目完成。对某个版本完成所有修改后，编辑人员或 ArcSDE 管理员将与 DEFAULT 版本进行协调，以解决出现的任何冲突。随后该人员会将修改提交到 DEFAULT 版本，从而将修改集成到已发布的数据库中。此时可以删除子版本。
可以限制用户对 DEFAULT 版本的访问权限，以强制执行此工作流并确保 DEFAULT 版本不会被修改。ArcSDE 管理员可以将 DEFAULT 版本的权限设置为受保护；这样允许用户继续查看 DEFAULT 版本，但将他们的访问权限级别限制为只读。任何想要修改数据的编辑人员都必须创建新版本。
如果只读用户不需要在更改被提交到 DEFAULT 版本后立即看到更改，则可以从 DEFAULT 版本创建一个受保护的静态版本供这些用户使用。应该在压缩数据库并重新构建索引和统计数据后创建此版本。这样做可确保表示只读版本所需的所有行都存储在基表中，并且数据库以最优性能运行。在这种情况下，不会对只读用户的数据库版本（下图中的 FastTrak）进行任何更改，因此不必执行版本差异查询，并且数据库统计数据和索引不会过期或产生碎片。在执行完每次计划的数据库压缩后，将会重新创建此版本，允许只读用户访问自上次数据库压缩后所进行的更改。
 |
优点：
- 简单易用：每个工作单元都是按版本在逻辑上分离的。
- 支持跨多个编辑会话的长期事务以及创建替代设计，允许编辑人员在不影响生产数据库的情况下制定计划。
- 从 DEFAULT 版本创建新版本可保护数据库的生产视图免受无意修改的破坏。各个工作项目会在完成后与生产数据库集成。
- 支持批处理协调/提交过程。
缺点：
- 与所有多层版本配置相同，版本增量表中保存的行越多，对版本查询性能的潜在影响越大。定期压缩数据库和更新 DBMS 统计数据可以最大限度地减少此开销。
多个含子项目的项目
与同时编辑或多个项目方法提供的工作流结构相比，复杂项目需要更加精细的工作流结构。这些项目可进一步分为多个功能或地理单元，根据这些单元将制定出更复杂的版本化等级。例如，一个设计并新建购物中心的项目可能具有几个不同的建造阶段，它会细分为东区和西区或按建造活动细分，如建筑、公共设施安装或景观美化。
 |
对于涉及不同团队和多个独立工作单元的大型项目，多层版本树是组织工作流的有效方式。负责同一项目不同方面的团队可以创建自己的版本来保存更新内容的私有视图。项目完成后，各个版本会被协调并提交回 DEFAULT 版本，并成为已发布数据库的组成部分。
优点：
- 支持复杂项目
- 支持跨多个编辑会话的长期事务
- 支持自动批处理协调与提交过程
缺点：
- 必须按顺序协调与提交版本，从与 DEFAULT 版本距离最远的版本开始，然后依次向后移动。换句话说，DEFAULT 版本的第三级版本（曾孙版本）必须被提交到它们的父版本，即 DEFAULT 版本的第二级版本（孙版本）。这些第二级版本随后被提交到 DEFAULT 版本的第一级版本（子版本）。最后，第一级版本（子版本）被提交到 DEFAULT 版本。
在每个子版本提交到各自的父版本后，可以删除子版本。
- 只能在直接连接的版本间执行协调和提交；不能跨版本路径进行协调与提交。
- 维护复杂的版本树可能会带来一些相关的性能开销：版本增量表中的行越多，对查询性能的潜在影响越大。
分阶段的项目
许多项目要经过一组预定或规定的多个阶段，其中每个阶段都需要工程设计、管理或法律批准，才能进入下一阶段。例如，在公共设施领域，常规项目阶段包括运作、计划、接受、施工和完工。这种特别过程本质上具有周期性：最初会将工作指令指定给工程师，随着项目经过各个阶段会对其进行修改，最后将其与生产数据库完全集成。
在此方法中，会为此过程的每个阶段都创建一个版本：初期设计或计划版本、批准版本和施工阶段版本。随着项目逐步向前推进，每个阶段都会经过审核和批准，然后被下一版本取代，直至达到最后一个阶段并完成该阶段。可以根据需要保存较早版本作为历史参考或者删除。
 |
项目完成后，可以立即对构造出的版本进行协调并直接提交到 DEFAULT 版本，而不必协调与提交谱系中的先前版本。
优点：
- 此方法适用于经过一系列阶段的项目，其中各个阶段必须被隔离为不同的工作单元。
- 与其他所有多层配置相同，此工作流允许编辑人员在不影响生产数据库的情况下制定计划和设计替代方法。
- 更改可以直接提交到 DEFAULT，这将消除按版本树逐级向上提交更改到 DEFAULT 版本所需的开支。
缺点：
- 不适用于批处理协调与提交过程
存档
许多项目的关键要求是在数据库随时间改变的同时保存数据库的各种状态。地理数据库可能需要支持的一些典型查询包括：
- 数据库在指定时间是什么样的？
- 特定要素是如何随时间变化的？
- 假定在某个日期从数据库中移除了一个要素，在已删除要素的之前位置当前存在哪些要素？
保存历史记录的一般要求是保留 DEFAULT 版本的存档，因为它通常代表已发布的数据库版本。对 DEFAULT 进行编辑或者从其他版本协调更改并提交到 DEFAULT 都会使 DEFAULT 发生更改。可以将地理数据库设置为自动记录这些更改。地理数据库内置此功能；不需要任何其他数据建模或应用程序自定义即支持自动存档功能。
某些项目需要存档除 DEFAULT 以外的版本。由于版本表示在其被创建时父版本的状态，您可以创建一个只记录父版本在特定时间点状态的版本。例如，可以根据设计版本创建新的历史版本。当设计版本被协调并提交到父版本时，将保留历史版本作为设计版本在特定时间点的记录。
 |
有关存档的详细信息，请参阅存档过程。
分布式数据管理
某些项目需要两个或多个远程办公室处理相同的数据。每个办公室都需要对数据库进行本地访问，因此会各自创建一个数据库副本。在一个地点对数据进行更改时，更改也必须应用到其他地点的数据。要保持数据库各副本间的同步，站点可以定期相互传输更改。此功能称为地理数据库复制。
 |
通过复制还可以在路途中获取地理数据库的子集并进行离线编辑，这是现场维护团队的一般要求。返回办公室后，可以重新连接到网络并将更改合并回生产数据库。
对于不得不通过慢速网络编辑数据的人员，复制也是很有用的。在这种情况下，通过复制可将数据的子集提取到本地计算机，这样不必通过网络通信即可对数据进行处理。完成编辑后，可以通过网络传输更改，将其合并回生产数据库。有关详细信息，请参阅使用分布式数据的情形。