我想做一个数据库，可以存储任何类型的对象，并为每一类对象不同的特征。
给出我在不同论坛上问的一些问题，解决方案是http://en.wikipedia.org/wiki/Entity-attribute-value_model或http://en.wikipedia.org/wiki/Xml在存储前进行某种验证。
你能给我一个替代以上的方法或一些优点或例子，以帮助我决定哪种方法对我来说是最好的吗?
感谢
UPDATE 1:您的数据库是读密集型还是写密集型?将两者->拍卖引擎你会从SQL Server转移到另一个平台吗?我不会移动它，我将使用WCF服务向移动设备公开功能。您计划如何向应用程序提供数据?面向DAL的实体框架和面向业务的WCF服务层人们会通过你控制之外的方式连接到你的数据吗?没有
虽然@marc_s的警告是正确的，但无可争议的是，在某些情况下，关系模型只是不够灵活。多年来，我一直在使用一个数据库，它大部分是直接关系的，但有一小部分EAV。这是因为用户可以在试验中随时为观察目的而发明新的属性。
无可否认，查询和报告是很尴尬的，举几个例子，但没有其他策略可以满足这里。我们将存储过程与T-Sql的pivot一起使用，为报表提供扁平的数据结构，并为显示提供带有动态列的网格。一旦基础设施建立起来，它就会变得非常舒适。
我们从来没有考虑过使用XML数据，因为它还不存在，除了它的常见限制外，它在我们的上下文中还有一些缺点:
- EAV数据查询量大。由于特殊的语法，开发团队需要的不仅仅是标准的sql知识。索引是可能的，但是"在数据修改期间维护索引是有成本的"(根据MSDN)。
- 当涉及到数据处理和报告时，XML数据类型远不如常规表和字段容易访问。
- 用户几乎不会获取一个实体的所有属性值，但无论如何，整个XML都必须被处理。
并且，并非不重要:XML数据类型(还)不被实体框架支持。
所以，总而言之，我会选择尽可能多的关系设计，但必要时使用EAV。拍卖项目可以有一些固定的字段和EAV的灵活数据。
我将引用另一个问题的答案:
由:
- <
- 存储/strong>。如果您的值将经常用于不同的产品，例如衣服，其中属性"size"和尺寸值将经常重复，则您的属性/值表将更小。同时，如果值将是相当独特的，可重复的(例如，属性"页数"的书的值)，你将得到一个足够大的表的值，其中每个值将链接到一个产品。
- 。这个方案并不是项目中最薄弱的部分，因为这里的数据很少被改变。请记住，您总是可以对数据库模式进行反规范化，以准备类似于dw的解决方案。如果数据库部分也很慢，你可以使用缓存。
- 弹性这是解决方案中最强的部分。您可以轻松地添加/删除属性和值，并将值从一个属性移动到另一个属性!
XML存储更像NoSQL:您将放弃数据库功能，并明智地准备您的解决方案:
- 不丢失数据完整性。
- 不要在应用程序中重写所有数据库功能(这是没有意义的)
我认为对于任何人来说，在讨论中添加任何有效的评论都缺少太多的上下文。
- 数据库是读密集型还是写密集型?
- 你是否会从SQL Server转移到另一个平台上?
- 您计划如何向应用程序提供您的数据?
- 人们会通过你控制之外的方式连接到你的数据吗?
首先，除非确实无法事先知道结构，否则不要采用这两种方法。因为不想实际定义需求而使用EAV或XML将导致不可维护的混乱和糟糕的执行混乱。通常至少90%以上的字段(基于我自己经验的保守估计)可以提前知道，并且应该在普通关系表中。只对事先不知道的结构使用特殊技术。我怎么强调都不为过。EAV表看起来很简单，但实际上很难查询，特别是对于复杂的报表查询。当然，将数据输入它们很容易，但将数据取出却非常非常困难。
如果您确实需要走EAV路线，请考虑在应用程序的这一部分使用nosql数据库，其余部分使用关系数据库。Nosql数据库只是更好地处理EAV。