存储元数据库

Question

我在这个问题上与同事有点不同意。首先，环境（有保证的，不会改变）：

• SQL Server 2008 R2的
• ASP.NET MVC 3
• C＃

而现在，这种情况下：我在一个应用程序上工作，这将使用户能够收集用户的输入并将其存储起来用于以后的报告。收集输入的方法是可以放在页面上的各种控件。收集数据不是问题;存储它。

数据库中的数据库

我按照它应该被存储为键值对的集合概念（在这个例子中，一台名为ResponseItems）：

+----------+----------+----+-----+ 
|ResponseId|FormItemId|Name|Value| 
+----------+----------+----+-----+ 

在哪里ResponseId和FormItemId构成主键，ResponseId与Response表有关，因此：

+----------+------+------+-------------+ 
|ResponseId|FormId|UserId|SubmittedDate| 
+----------+------+------+-------------+ 

和与一个FormItem表FormItemId：

+----------+------+----+-----------------+ 
|FormItemId|FormId|Type|InstantiationData| 
+----------+------+----+-----------------+ 

哪里FormId是一样的，在Response表FormId，引用Form表，这是不一样重要说明。

XML序列化

我回来的应答序列化窗体组件和响应的XML更有意义，这样，它需要在表计少批量，只留下一个形式表：

+------+--------+ 
|FormId|Elements| 
+------+--------+ 

以及所有实例化数据存储在Elements中每个表单元素的XML数据中。响应被进行类似记载：

+----------+------+-------------+----------------+ 
|ResponseId|UserId|SubmittedDate|ResponseElements| 
+----------+------+-------------+----------------+ 

短期问题后，龙前言

我想到的第一个想法是更清洁和更容易报告。你怎么看？

作为最后一点，双方都有更多的表格，因为每次用户编辑表单时都会对表格进行版本控制。

Answer 1

第一种方法称为实体属性值（EAV）。在我看来，这是从来没有存储关系数据的好方法。在采用该设计之前，您应该阅读一篇名为Bad CaRMa的文章。

我还在我的演示文稿Practical Object-Oriented Models in SQL和我的书SQL Antipatterns: Avoiding the Pitfalls of Database Programming中讨论了EAV的缺点。

在这两种设计中，我更喜欢XML方法。它基本上是Martin Fowler的Serialized LOB模式。您可能还想读How FriendFeed Uses MySQL to Store Schema-less Data。他们的方法不是特定于MySQL;它可以在SQL Server或任何其他RDBMS中工作。