XML模式迁移

发布时间：2020-12-16 23:01:51 所属栏目：百科来源：网络整理

导读：我正在开发一个项目,我们需要以 XML格式保存数据.问题是,随着时间的推移,我们希望数据的格式/架构发生变化.我们希望能够生成脚本以跨不同的模式版本迁移我们的数据.我们将产品分发给成千上万的客户,因此我们需要能够在客户站点运行/应用这些脚本(因此我们不

我正在开发一个项目,我们需要以 XML格式保存数据.问题是,随着时间的推移,我们希望数据的格式/架构发生变化.我们希望能够生成脚本以跨不同的模式版本迁移我们的数据.我们将产品分发给成千上万的客户,因此我们需要能够在客户站点运行/应用这些脚本(因此我们不能手动进行转换).我认为我们正在寻找的是某种XML数据迁移工具.在我看来,理想的工具可以：

>执行两个模式的“XML diff”以识别添加/删除/更改的节点.
>允许我们指定转换函数.因此,例如,我们可能会向我们的架构添加一个新元素,该元素是旧元素的函数. (例如,新元素C,其中C = A B,A B是旧元素).

所以我认为我正在寻找一种XML差异和补丁工具,它也可以应用转换功能.我正在寻找的一个工具是Altova’s MapForce.我相信其他人必须处理XML数据格式迁移.你是怎么处理的呢？

编辑：
一点澄清.我计划做的“差异”是在架构或.xsd文件上.将对遵循给定模式的特定数据集进行实际更改.这些数据集将是.xml文件.因此它是模式的“差异”,以帮助确定需要对数据集进行哪些更改以将它们从一个方案迁移到另一个方案.

解决方法

“做两个模式的”XML diff“来识别添加/删除/更改的节点.”

XSD是文本,所以这是微不足道的.

但是,如果您对XSD进行了戏剧性的结构更改,那么自动差异将很大程度上无用.

如果您对XSD进行小的,美观的更改,这可能会有所帮助.

“允许我们指定转换函数……”

这不是很好.可悲的是,存在一些微不足道的变化的可能性(“新元素C,A B是旧元素”)几乎为零.为什么要做那种微不足道的改变？

不,当您“……将产品分发给成千上万的客户”时,您不会做出微不足道的改变.您可以保存更改,使它们真正成为史诗,并“创造重要价值”.

不,自动架构迁移的几率几乎为零.

相反,设计可迁移性.

>确保版本号在XSD路径中很突出.理想情况下,在XSD名称中.
>每个XSD变更都是严??重治理问题(SGI?).每个人都参与其中.然后你就可以编写迁移脚本了.不是之后.没有工具.但作为XSD变革的一部分.

架构不会自发地改变.有人因为某个原因改变了它们.有人可以指定更改,以便其他人可以编写(或更新)迁移脚本.

对于“自动化”工具来说,这远远不够严重.这需要真正关心真正人的大脑,好像他们的工作依赖于此.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!