现代 RDBMS 支持 XML 列类型和在存储过程中处理 XML 的功能。从历史上看,我总是将分层数据(无论是 OO 对象还是 XML)映射到关系表。鉴于对 XML 的广泛数据库支持,我应该改变我的方式吗?
11 回答
我有一个很好的现实生活例子。我的一个客户经常从他们的供应商那里收到一个包含一些重要数据的 XML 文件。它嵌套很深。他们需要将其与之前的 XML 文件进行比较,以了解发生了哪些变化。如果数据库中没有 XML 支持,我必须构建一个工具来遍历 XML 节点并在关系数据库的表中查找匹配项。我可以使用一些 XML-XML 比较工具,但其中一些检查与其他一些不是来自 XML 文件的数据相关,我需要将所有这些数据结合在一起。好的,所有这一切都不是什么大不了的事,但仍然 - 使用 XML 数据库,您可以获得开箱即用的功能。
如果您没有看到需要,请不要更改!
有时您必须持久化不具有已知结构的数据,或者其结构非常不稳定。在这些情况下,无需创建表,只需将 XML 保存到现有表中
我会再次使用它的唯一原因是何时可扩展性和灵活性。
如果可以避免,xml(xpath)和维护(命名空间)的开销真的不值得麻烦。我们之前在 xml 中存储了大量数据,并使用标量函数来检索它,但是它太慢了,并且导致 xml 结构或命名空间更改的巨大头痛。
但是灵活性很棒。您可以随时添加新属性,您可以在其中包含不需要适当列的项目/客户/作业特定数据。XML 不必处于静态结构中 - 您只需要一个可以生成实例的工厂来处理不同的 XML(这需要与项目/客户端/作业相关)。
当向现有系统添加新表时,尤其是现有数据很多且不易修改的系统时,我将添加一个 XML 列。将来,如果我需要向该表中添加另一列,我可以简单地利用 XML 列,而不必感到沮丧并不得不进行大量返工。
总之,您不是从将基本属性放入 XML 开始的。但是,当您知道您的表可能需要扩展时,您应该添加 XML,正是因为它为您提供了扩展选项。
这是我工作的系统中的一个真实示例。我们有一个核心系统,并在 java 中创建客户特定的代码。根据正在交易的客户,可能会调用不同的类。有时,此自定义代码需要存储一些内容,我们将其放入相关表的 XML 列中。这使我们免于对阳光下的一切进行建模。添加新客户通常只意味着编写和安装 java 代码。
缺点是在 XML 列上报告、查询和更新更加困难。没有像检查约束等通常的良好数据库功能。
我使用 XML 列类型来存储我们从第三方服务接收到的所有关键业务消息的副本。由于几个原因,它非常方便。
1)在数据损坏的情况下,我们可以回溯以查看何时以何种格式输入了哪些数据。
2) 系统的未来开发工作可以基于来自日志表的真实数据 - 只需反序列化并使用数据,就好像它来自对 3p 服务的调用
3) 确保基础设施人员忙于为数据库分配磁盘空间服务器。;)
例如,您从某个其他系统获取 XML 文档,这些文档具有您想要存储的非常丰富或复杂的结构;但是您只需要一些定义明确的查询来检索该数据。在这种情况下,只需解析生成一些索引所需的数据,并将整个 XML 结构存储在单个字段中。
为此,您不需要数据库引擎上有太多特定于 XML 的支持,但它仍然有助于保持查询的表达性。
除此之外,我猜想一些具有良好 XML 支持的 DMBS 可以让您简单地存储 XML 文档,也许无需指定如何对其进行索引。您只需使用 XQuery 并希望它以某种方式优化以满足您的需求。
到目前为止,我还没有存储 XML 的需要,但我经常使用从存储过程返回 XML 的能力。它使一些东西非常有用——主要是报告。我可以运行一个 SP 来生成报告,以 XML 格式发回结果,然后使用 XSLT 很容易地在网站上显示结果。
假设您有一个具有属性的实体。您可以将所有这些属性存储在 XML 中,而不是创建单独的属性表。XML 会更灵活。
您可以直接在 SQL Server 中处理 XML 数据。例如,您可以应用 XPath 表达式并将过滤后的结果集发送到客户端。SQL Server 功能以后可以建立在 XML 处理能力的基础上。
上述功能来自 MS SQL Server 2000或 2005。
您可以在其中存储用户生成的 XML。
如果像 stackoverflow 这样的网站使用某种 XML 标记而不是标记,您可以将问题/答案作为 XML 存储在数据库中。您可能会发现自己试图解析这个用户生成的 XML 以寻找专有标签。
灵活性是原因之一。
如果您的数据结构可以变化,那么您仍然可以保留一个通用的 RDBMS 表,以及查询等,这些表与结构有些可变的数据一起使用。
如果您需要在某个时候添加字段,您可以在不更改 RDMS 表结构的情况下执行此操作,从而不会破坏其他所有人的查询。