可插拔数据存储架构

Question

我有一个可插拔的系统管理工具。 这种事情的体系结构是众所周知的（接口，发布/订阅等）。 数据存储如何呢？ 人们在做什么？

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

我的想法（SQL），不一定经过深思熟虑

• 每个插件在安装时都会简单地扩展架构。 在过去，更改架构是一个很大的禁忌。 现在数据库对此非常放松

• 插件有自己的表。 如果其中两个有一个实体（例如）个人，则有2个表p1_person和p2_person

• 插件有自己的数据库

• 发明一种灵活的方案，在其中对表进行软键入。 也许许多属性打包成一个属性。 最终的结果是拥有一个名为data的大表，其中包含表名和列名的键以及单个数据值。

不是SQL

• 对象数据库。 我没有这些经验。 任何人都希望传递经验。 例如db4o。 随着应用程序的发展，我可以更改对象的“模式”吗？

非SQL

• 这是目前的“状况”。 这些目标中的大多数似乎与我的需求略有不同。 任何人都想传递这些经验

对于开放式问题的道歉

Answer 1

我的建议是去阅读有关实体框架的信息

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

您对一个称为数据的大表的想法使我计算机中的仓鼠哭了；）

总的趋势是远离弱类型的架构，因为它们不能在编译时进行调试。 从诸如实体框架之类的东西中得到的是一个强类型的extenislbe模式，您可以使用linq对其进行编码。

对象数据库：像您一样，我还没有与他们进行过Massivley的比赛-但是，当我考虑它们的时候是.net缺少良好的ORM并编写ado.net代码的时代慢慢让我丧命。

至于NO-SQL，这些都是可以满足性能需求的数据库。 在这里发生大量小写的情况下，SQL的性能很差。 我的脸颊非常不好-它的性能很好，但是当您扩展到数百万并发用户时，一切都会改变。 我对没有sql的理解是，它是一种非合理化的格式，设计用于许多小的快速写入和读取。 使用这些网站的规模通常很大。

OK-回应

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

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

开始以为我误解了您要寻找的东西。 我发现数据库已成为我的第二天性，因为我已经花了很长时间了。

我还没有找到对脚本管理一丝不苟的替代品。