我有一个用于保存产品数据的 SQL 表。有些产品还有其他附加数据(例如:书籍有页数、封面类型;电影有时间长度等)。
我可以在 SQL 中使用单独的表来保留这些,保留 (name, value) 对。
我也可以将 XML 打包的数据保存在表的单个字段中。这不是一种标准化的方法,但对我来说似乎更自然。
我有一个用于保存产品数据的 SQL 表。有些产品还有其他附加数据(例如:书籍有页数、封面类型;电影有时间长度等)。
我可以在 SQL 中使用单独的表来保留这些,保留 (name, value) 对。
我也可以将 XML 打包的数据保存在表的单个字段中。这不是一种标准化的方法,但对我来说似乎更自然。
我在购物篮应用程序中做了类似的事情。我们需要在不创建太多模式的情况下将元数据附加到产品上,这会限制未来元数据的格式。我们将元数据保存为 XML。
我不这样做的唯一原因是您最终要对数据执行查询。只要确保你不会有一些愚蠢的人想要发布者元数据或其他东西的报告(这发生在我身上),你应该没问题。
如果您打算使用 XML 作为不正确定义数据库表的一种方式,这确实会导致架构上的缺陷。我不确定您的情况,这似乎很危险。但是键值对可能更糟。
The best thing is to use a specialist XML datatype, if your database has one. In addition to RageZ's list, Oracle as had an XMLType for ten years now (since 9i). The advantage of using XMLType is two-fold. It announces to the casual observer that the documents in this column are XML. It also gives you access to built-in functionality, such as validation with XML Schemas, should you want it. Other features could prove handy if you subsequently have to start referring to the contents of the XML. For instance, Oracle's XDB supports an XML index type which can dramatically improve the performance of XPath queries.
这取决于!
如果您希望产品的“形状”变化很大,那么 XML 是一个不错的选择。[如果您使用的是 SQL Server,您可以为 XML 字段编制索引。]
我不认为这是一个架构上的误解。只要确保您不想在查询中使用这些数据,因为它会很复杂。
再加上最近的 RDBM 具有处理 XML(MSSQL、Postgres、Mysql)的功能,因此您仍然可以使用这些数据。