动态数据库/关键 - 价值/实体 - 关键价值困境

时间:2011-12-22 20:52:47

标签: sql database non-relational-database object-relational-model

我多年来一直在编写关系数据库,但现在遇到了一个不寻常且棘手的问题:

我正在构建一个需要非常快速且易于定义的实体的应用程序(由用户提供)。然后可以创建,更新,删除这些实体的实例。

我能想到两种选择。

选项1 - 动态创建表格

第一个选项是编写引擎以动态生成表,并将数据插入到这些表中。但是,这会变得非常棘手,因为每个查询都需要是动态的,或者至少是动态创建的存储过程等。

选项2 - 实体 - 关键 - 价值模式

这是我能想到的唯一现实选择,我有5个表结构:

EntityTypes

EntityTypeID int

EntityTypeName nvarchar(50)

实体

EntityID int

EntityTypeID int

FieldTypes

FieldTypeID int

FieldTypeName nvarchar(50)

SQLtype int

FieldValues

EntityID int

FIeldID int

值nvarchar(MAX)

字段

FieldID int

FieldName nvarchar(50)

FieldTypeID int

“FieldValues”表有点像数据仓库事实表,我的所有插入/更新都可以通过填充“Key / Value”表值参数并将其传递给SPROC(以避免多次插入/更新)来工作)。

所有表都会被严格索引,我最终会做很多自连接来获取数据。

我已经阅读了很多关于Key / Value数据库有多糟糕的内容,但对于这个问题,它似乎仍然是最好的。

现在我的问题了!

  • 除了这两个选项之外,还有人可以提出另一种方法或模式吗?
  • 选项二对于中型数据集(最多100万行)是否可行?
  • 我可以使用选项2进一步优化吗?

任何方向和建议都非常感谢!

3 个答案:

答案 0 :(得分:2)

就个人而言,我只会使用像MongoDB这样的“noSQL”(键/值)数据库。

但是如果你需要使用关系数据库选项2是要走的路。这种模型的一个很好的例子是Alfresco Data Dictionary(Alfresco是一个企业内容管理系统)。它的设计与您描述的类似,尽管它们有多列字段值(对于数据库中可用的每种简单类型)。如果你为它添加一个好的缓存系统(例如Ehcache),它应该可以正常工作。

答案 1 :(得分:1)

听起来这可能是寻找问题的解决方案。您的域名是否有可能被重构?如果没有 - 还是希望。

  • 您对选项2的可伸缩性将在很大程度上取决于自定义对象的宽度。可以动态创建多少个字段?当每个实体有100个字段时,100万个实体可能会拖累...高效的索引可以使性能变得可以忍受。

  • 对于另一个选项 - 您可以拥有一个数据表,其中包含一些字符串字段,一些双字段和一些整数字段。例如,带有String1, String2, String3, Int1, Int2, Int3的表格。第二个表具有定义用户对象的行并映射“CustomObjectName”=> String1等。读取INFORMATION_SCHEMA和一些动态sql的存储过程将能够读取模式表并返回强类型记录集...

  • 另一个选项(对于SQL Server的最新版本)将存储具有id,类型名称和包含包含对象数据的XML文档的XML字段的行。在MS Sql Server中,可以直接查询,甚至可以根据模式进行验证。

答案 2 :(得分:0)

PErsonally我会花时间来定义尽可能多的attritbutes,而不是使用EAV来做所有事情。当然你知道一些属性。那么你只需要EAv来完成真正客户特定的事情。

但如果一切都必须是EAV,那么nosql数据库就是最佳选择。或者你可以使用relationsla数据库来处理一些东西,然后使用nosql数据库。