确实没有明确的职业清单 - 这取决于你想要做什么。但是，您还需要考虑以下几点：
- 并非所有SQL数据库都支持XML xpath（超出
blob like '%xxx%'）。也许你被困在数据库的旧版本上，它没有XML支持功能（即Mysql 4）。更轻松的SQL数据库，如Sqlite和hsql也属于这个阵营。
- 即使可以在数据库中搜索XML，它也不是最佳的。 XML的SQL搜索无法利用SQL Server内置的搜索优化（即索引）。
- 根据数据库的不同，您在数据库中使用XML文档也无法利用SQL Server的验证和类型功能。例如，Oracle可以进行XML模式验证，我没有看到Mysql可以。
- 您可以执行哪些查询的性能，不会与标准列查询进行比较。
- 数据库大小。如果将XML存储在数据库中，它将变得更大。你可以压缩它，但随后查询它将很难/不可能。
- Normalization问题可能会成为相关问题 - 也许您不希望在某些时候使用SQL来查询XML，但稍后它决定实际需要一些字段。您可能需要从XML中提取该字段并填充实际列以获得所需的性能...在这种情况下，您现在在数据库中有冗余信息。
利弊实际上取决于你将要存储的内容以及它的用途。
- 如果它本质上是二进制/配置信息，你只需要坚持一些地方，并且无论出于何种原因更喜欢坚持你的SQL数据库......好吧，关于查询的考虑是不相关的。在这种情况下，重要的问题涉及空间以及如何最小化空间（即压缩）。
- 如果有可能需要定期搜索XML，那么您就会面临查询速度慢和上面提到的冗余问题的风险。在这种情况下，您应该非常仔细地考虑您的长期设计：您真的需要将这些数据存储为XML吗？从该数据构造XML会更好吗？
在这两种情况下都有利弊，这取决于您的使用情况。
存储为XML本身的主要缺点是我们无法快速搜索特定数据。要执行搜索，我们必须检索并解析所有XML文件。
我们在其中一个项目中遇到过类似的情况。在讨论之后，我们采取了中间立场的方法：
所有主要信息（需要快速查询的信息）都存储在相关表中。我们也存储了XML;但是不是像这样存储XML，我们将XML保存到磁盘并在表中使用该文件路径。