可插拔数据存储体系结构

Question

我有一个可插拔的系统管理工具。这类事物的体系结构是很好理解的(接口、发布/订阅、.)。但是数据存储怎么样。人们是做什么的？

我需要插件能够添加新的实体，扩展现有的实体，建立新的关系等。

我的想法(SQL)，不一定经过深思熟虑

• 每个插件在安装时简单地扩展了模式。在过去，改变模式是一个很大的不-不；现在数据库非常放松这个
• 插件有自己的表。如果其中两个有一个实体(比如) person，那么就有两个表-- p2_person
• plugins和p1_person --它们都有自己的database
• invent --某种灵活的方案，其中的表是软类型的。可能有许多属性被打包到一个属性中。最终的结果是有一个名为data的大表，其键为表名&列名和一个数据值。

不是SQL

• 对象DB。我对这些没有经验。任何想要传递经验的人。例如，db4o。随着应用程序

的发展，我能改变对象的“模式”吗？

无SQL

• ，这是目前的“在哪里”。其中大部分的目标似乎与我的需求略有不同。有人想要传递这些

的经验

为开放式问题道歉

Answer 1

我的建议是阅读有关实体框架的内容。

您所描述的许多情况都可以使用表继承来解决(非常优雅)。

你对一个叫做数据的大桌子的想法让我的电脑里的仓鼠哭了;)

一般趋势是不使用弱类型模式，因为它们不能在编译时进行调试。您从类似于实体框架的东西中得到的是一个强类型的扩展模式，您可以使用linq对其进行编码。

对象数据库:和您一样，我也没有和它们玩过massivley --然而，当我考虑它们的时候，.net没有很好的ORM，编写ado.net代码也在慢慢地折磨着我。

至于NO，这些数据库满足性能需求.SQL在这里的情况下表现很差，这里有很多小的写操作。我说不好的酒廊-它的表现非常好，但当你扩大到数百万的并发用户，一切都改变了。我对no的理解是，它是一种非合理化格式，可用于大量小型、快速写入和读取。使用这些网站的规模通常非常大。

好的-作为回应

目前，我非常幸运地参与了一个绿色领域项目，因此我正在使用EF来生成我的模式。在非绿地项目上，我使用sql脚本更新我的表结构。至于在sql中实现表继承--一旦您知道了这个概念，它就非常容易了，它本质上是一对多的关系，约束条件是它永远只能是0-1。

我不会编写更新数据库结构的.net代码.听起来像是一场灾难等着我。

开始觉得我误解了你要找的东西。我发现数据库是第二天性，因为我花了很长时间在它们上。

我还没有找到一个替代品，因为我对脚本管理非常谨慎。