大的XML包裹和使用属性或元素
我知道,对于属性与元素辩论没有普遍的答案(并且我通读了我在其中看到的其他问题),但是对这种特定情况的任何洞察都将不胜感激。大的XML包裹和使用属性或元素
在我们的案例中,我们将从一个记录系统接收大量的主数据和事务数据,并将其合并到我们自己的数据库中(每晚一个演出)。我们收到的信息基本上是一个换一个,在我们的表中的记录,因此,例如客户的名单将(在我们的旧版本):
<Custs>
<Cust ID="101" LongName="Large customer" ShortName="LgCust" Loc="SE"/>
<Cust ID="102" LongName="Small customer" ShortName="SmCust" Loc="NE"/>
....
</Custs>
但是我们一直在讨论的优点
<Custs>
<Cust ID="101">
<LongName>Large Customer</LongName>
<ShortName>LgCust</ShortName>
<Loc>SE</Loc>
</Cust>
<Cust ID="102">
<LongName>Small Customer</LongName>
<ShortName>SmCust</ShortName>
<Loc>NE</Loc>
</Cust>
....
</Custs>
因为文件太大,我不认为我们将使用DOM解析器来尝试这些加载到内存中,我们也不:移动到这是基于多个因素,例如结构有任何需要查找文件中的特定项目。所以我的问题是:在这种情况下,当你需要考虑大量数据和性能需求时,一种形式(元素或属性)通常会优于另一种形式(元素或属性)?
如果性能是唯一的要求,我认为你必须去与属性,只是因为它占用更少的空间。我认为这些元素没有任何优势。
我们做了一些不同格式的实验并收集他们的表现结果。最终我们决定坚持使用Attributes。感谢您的输入! – inyourcorner 2008-11-28 18:37:03
我已经使用这两种方法与非常大的文件与DOM和逐行阅读器。当然,您需要使用逐行阅读器才能获得超大文件的良好性能。除此之外,我的直觉是属性更有效率,但我没有硬数据支持这个观点!
如果某人一次为您提供1GB数据,并且您关心的是性能,那么您应该重新审查使用XML作为传输格式的决定。您不会将数据解析为DOM,因此您无法真正利用XML为您提供的优势(例如CSV) - 确保格式良好,架构验证,转换和查询等。
现在您正在考虑转换为您将要处理的一半数据是标记的格式。这是什么感觉?
我来自于当你只是一个工具时,你有倾向于感知所有问题的XML指甲学校,甚至我不会'为此使用XML。
如果您打算在通过普通的旧式DTD进行处理之前验证xml,那么“属性方式”更为可取。没有规则来验证DTD语言中的一个元素内容,但是一些基本规则可以应用于属性值。
如果您打算使用XSD或根本没有验证,那么我会选择最可读的表单,其中恕我直言是“元素方式”。
无论XML来自何处,XML验证都应该是处理任何XML的第一步。它使得您的应用程序更安全,代码更小,因为在您的代码之前进行了许多检查,甚至检查XML数据。 XSD应该是首选,因为它的语法允许检查偶数据转换(即float,元素或属性内容中的日期字段)。 con,它比普通的DTD文件复杂得多。
交换XML格式的数据并不一定坏,只是因为它是一个大的数据集。
不过,如果你正在交换非常大的XML文件,你可能要考虑为了节省时间和带宽使用ZIP,GZIP等传输之前对其进行压缩。
如果您正在交换数据库信息,可以考虑(在发送之前,甚至压缩的SQL文件)格式化的信息,SQL语句;特别是如果这是你最终把XML转换成什么的话。
顺便说一句,如果你可以使用一个拉解析器而不是SAX解析器。他们更容易合作。使用SAX,您不必担心在回调之间保存状态。 – 2008-11-11 19:16:47
感谢大卫的头! – inyourcorner 2008-11-12 16:31:31