Question

如果没问题，建议使用xml列存储用户界面可能提供的任何额外数据？

例如，假设一个Employee表

CREATE TABLE Employee
(
    EmployeeId int not null,
    Name nvarchar(300) not null,
    Phone varchar(30) null,
    Email varchar(320) null,
    Address nvarchar(max) null,
    Data xml null
)

Data可能包含许多值，例如其他电话号码，评论......

我们希望我们所有的客户都会在Employee中询问不同的字段，而且每次想到要添加的新字段时我们都不想弄乱数据库结构。

我们希望存储在xml列中的数据不经常访问数据。除了在浏览员工列表时可以查看，还可能需要打印数据。所以我们确实需要沿着数据存储数据类型（有点像数据集序列化其数据）

这是存储未知额外数据的好方法吗？

被修改 给出了一个更好的例子

更新我还没有选择答案，因为我正和我的团队讨论你们建议的不同方法。

Answer 1

你可以这样做：

[EmployeeField]
-----------------------------------------------------
EmployeeID    EmployeeFieldName    EmployeeFieldValue

事实上，.NET Membership用于具有动态字段的用户配置文件的方法相同。许多业务应用程序使用相同的方法来存储动态的客户特定输入。

相信Spencer Ruport的评论，这种方法被称为Entity-Attribute-Value model (EAV)。

Answer 2

你正在使用关系数据库模型为自己切断自己。关系数据库是围绕静态数据结构的思想构建的，并且能够轻松快速地进行查询。即使采用EAV结构作为“New in town”也表明与此相反，尽管它可能比简单的XML数据转储更好。

如果customer是一个奇怪的，其余的数据都没问题，那么这样做可能很好，尽管我肯定会采用EAV方法。如果您的大多数表都是这样的，那么就该重新考虑您的数据存储方法了。

Answer 3

XML列是一种非常灵活的格式，但对于搜索也非常糟糕。用户“New in Town”指向另一个标准解决方案，不太灵活，但能够选择和加入额外属性。

Answer 4

我个人更喜欢将额外的未知数据添加为单独的表格。这允许您允许无限数量的选项（只有ID，名称，类型（？ - 可选）和数据列），但提供允许选择性更新/删除的额外好处。

如果您将其作为单个数据blob执行，则每次更改aux数据的任何部分时，都必须替换整个数据字段。

Answer 5

取决于数据是什么。如果在关系结构中建模并不容易，那么你提出的建议（实际上只是Serialized LOB）就可以了。

Answer 6

如果要在查询中使用数据，我建议不要将其放入xml字段中。是的，有办法从xml字段查询数据，但我没有发现它们是有效的。

Answer 7

是的，没关系。是否推荐取决于您的具体情况。我们使用Oracle做类似的事情并且灵活性很好但是我们的自定义Web框架（生成基于XML编写的模块的Web页面/应用程序的Java servlet）大量使用XML，我们有适当的系统来处理存储数据单个XML列，所以我的观点和经验基于方便的场景。

例如（我知道这对人们来说可能听起来很可怕），如果你要根据XML中的数据进行搜索，这可能最初会产生问题，因为每次运行XPath并从每行的XML中提取数据你搜索是一个巨大的性能打击。我们有一个类似于物化视图的系统，它利用触发器和存储的查询。每当更改基本表（包含XML列）中的行时，触发器触发，运行查询并从XML中提取数据并将其插入到关系表中，而关系表又可以查看它以确保您不会不修改关系数据（因为这不会反映回XML）。

对于大量基于Web的表单执行CRUD操作的目的，其中模式和数据模型可能经常更改它是非常棒的。这意味着您可以提取XML片段并立即获得页面的基础模型，并保存它就像简单地将XML片段重新放入其中一样简单。对于快速只读访问，我们可以即时访问XML的关系视图

Answer 8

我假设您还必须在XML中查询和搜索Employee属性。

如果使用XML模式并创建必要的XML索引，则可以。您也可以使用EAV关系模型，可能会更高效。如果您要实施EAV模型，必须必须阅读Best Practices for Semantic Data Modeling for Performance and Scalability白皮书，由SQL客户咨询团队撰写的白皮书处理常见的陷阱和严重问题设计了EAV模型。

作为旁注，只存储一个实体的ID和NAME，因为它与员工一样富有属性，这听起来就像你真的抛弃了球。您至少应该添加您希望大多数客户使用的公共属性，并且只依赖可扩展模型（XML或EAV）来获得您无法预见的 extra 属性。

<强>更新

既然我们在这里，那么这里也是关于XML最佳实践的SQL CAT白皮书：

XML Best Practices for Microsoft SQL Server 2005

Performance Optimizations for the XML Data Type in SQL Server 2005

Answer 9

是的，如果额外的数据没有“链接”到任何其他表格，并且您不需要经常搜索它。如果你每个人都有多个用户编辑的不同部分为同一名员工提供额外数据，然后仔细考虑您的设计。

因此，如果您的额外数据只是一个“注释”字段，并且碰巧有每个客户预定义的标题，那么就可以了。

将这些额外数据放在[EmployeeField]表中没有任何好处，因为它只会使数据访问代码更加复杂，而不会使您利用数据库的强大功能。

而是存储每个数据项的类型，我认为你应该有一个元数据表，它存储给定客户希望拥有的每一位额外数据的类型，名称和“显示名称”。您可能还需要存储客户希望用于输入额外数据的表单布局。

是否可以使用XML列存储额外数据？

9 个答案: