我们将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的成本是合理的。

最终，项目需求将决定我们应该做什么，但是静态类型和性能是要考虑的主要优点。

使用模式的一大优势在于，它有助于确保项目中的每个人都同意应如何布局XML文档。另外，通过使用模式，我们可以在XML解析器中启用验证，从而更容易分辨出某些代码失败(因为该代码中给出了一些错误的XML)。

不利的一面是，维护模式可能会很麻烦，根据项目，可能不值得付出努力。

如果没有模式，最终将自己重新实现所有验证(或者根本不进行验证，并在无效输入时崩溃)。 XSD解析器/验证器为我们完成所有这些工作，并由其领域的专家进行优化和调试。我们为什么要自己重做所有这些工作？

嗯，正如其他帖子和问题中所述，XSD将确保我们在XML的正确位置使用正确的类型，并且在更改其结构之前必须三思。

但是，如果我能说的话，XSD确实太冗长了。有时，用条件内容描述一个复杂的结构真的很麻烦。

希望XSD不是验证XML的唯一方法，更简单的方法是使用RelaxNG，尤其是它的紧凑语法，它的可读性比我们用XSD想象的要好。

XSD不是唯一可用的XML模式。请改用http://relaxng.org/。 RelaxNG使我们可以用XML表示模式，而不必像XSD那样学习另一种数据"语言"。