我们将 Microsoft SQL Server 2005 中的 XML 数据类型用于一个项目。团队的一些成员和我认为我们也应该使用 XSD，而其他阵营的成员则认为我们应该保持 XML 临时性而不是将它们视为“类型”。
XML 旨在为许多文本配置文件带来结构和中心性，而这些文本配置文件是维护的噩梦。
我们使用的是 .NET 3.5/C#，并且我们的表是用适当的数据类型设计的。我的论点是，我们已经在思考为什么要打破这种方法，因为它是 XML 的“面向类型”。最初的问题是由于缺少文本文件的类型。不使用“类型”方法会使我们面临同样的问题。
可能是我对 XML 模式的好处的理解不正确。那么使用 XML 模式的优缺点是什么？
在没有 XSD 的情况下保留 XML 存储库（在我看来）类似于拥有一个所有类型都声明为 VARCHAR(n) 的数据库。你不关心你得到什么样的输入，你只想要输入。
XSD 确保您的 XML 具有您期望的输入类型。它们为您的模型提供结构，正是您正在寻找的东西。
不幸的是，即使是 XSD (W3C) 的作者也明白 XSD 是一种非常糟糕的技术。也就是说，它的意图不一定是坏的。C# 的主要优点之一是它是静态类型的。静态键入您的 XML 文档给它们带来了同样的好处。这里最好的可能是对您的类进行逆向工程，以使用 XML 序列化属性生成 Schema。当您执行此操作时，C# 将为您的 XML 文件创建一个自定义数据读取器，这将显着提高性能。
XML 的最大成本之一是它必须进行字符串解析。您可以对 XML 文件（例如它们的结构）做出的假设越多，您的性能可能就越好。
因此，最终像许多事情一样，它们是否足以需要性能优势来证明开发人员时间的成本是合理的。或者是否有足够强烈的愿望使用静态类型系统来证明编写 XSD 的成本是合理的。
最终，您的项目需求将决定您应该做什么，但静态类型和性能是需要考虑的主要好处。
好吧，正如其他帖子和问题中所说，XSD 将确保您在 XML 的正确位置使用正确的类型，并且在更改其结构之前必须三思而后行。
但是，如果我可以这么说的话，XSD 确实过于冗长了。有时它真的是一团糟，描述一个复杂的结构，有条件的内容。
希望 XSD 不是验证 XML 的唯一方法，更简单的方法是使用RelaxNG，尤其是它的紧凑语法，它比您想象的 XSD 更具可读性。
使用模式的一大优势是它有助于确保项目中的每个人都同意 XML 文档的布局方式。此外，通过使用模式，您可以在 XML 解析器中启用验证，从而更容易判断某些代码何时失败，因为它给出了一些错误的 XML。
不利的一面是，维护模式可能会很痛苦，并且根据您的项目可能不值得付出努力。
如果您没有架构，您最终将自己重新实现所有验证（或根本不验证并在无效输入上崩溃）。XSD 解析器/验证器为您完成所有这些工作，并由其领域的专家进行优化和调试。你为什么要自己重做所有这些工作？
XSD 不是唯一可用的 XML 模式。请改用 http://relaxng.org/。RelaxNG 让您可以用 XML 表达模式，而不是像 XSD 那样需要学习另一种数据“语言”。
开发 XML 的一个重要原因是它允许以更多方式使用来自更多来源的数据，因为它已成为在任意数量的计算机系统之间交换数据的广泛接受的标准。