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