灵活的持久层

我正在设计一个ASP.NET MVC 2应用程序。目前我正在利用Entity Framework 4和可切换的SQLServer和MySQL数据存储。灵活的持久层

最近要求应用程序要求用户定义的模型/实体被操纵。现在我不确定SQL /关系数据库是否合适。例如，用户应该能够定义一个'Employee'以及它具有的属性 - 在运行时有效地添加/删除表和列，而不是添加/删除'Employee'对象。

SQL是否不适合这个？是否有选项允许我保留在关系数据库结构中并仍然满足此要求？在实体框架中，我可以“即时”重新生成.edmx文件，还是有可以实现类似目标的替代方案？
我简单地看了一下其他选项，如'基于文档'dbs和'无模式/无sql'数据库，如MongoDb。我还研究过一些序列化格式，例如Google的Protocol Buffers，JSON和XML。根据你的经验，这些特别适合于这个目的吗？序列化性能不是一个大问题。

该应用程序处于起步阶段，我没有时间限制。从本质上讲，我可以随心所欲地重写它，所以如果报废并重新开始是一个更好的选择，我对此非常开放。你有什么建议？提前致谢！

2010-09-01 Alex

SQL允许您通过ALTER TABLE命令添加和删除列，但目标受众的技能组是多少？我问，因为我害怕人们定义他们的数据模型的想法。多数人对参照完整性或标准化一无所知 - 一直认为Excel电子表格。曾见过在Access中设计的数据模型？ – 2010-09-01 04:39:00

在看看我建议的选项之前（如果您还没有完成:-)，您需要明确定义用户可以定义的内容。一旦你有了这些，你就可以推断出所需的灵活性水平，从而推断出工作所需的数据存储类型。

另一个建议是，如果他们的客户要求能够以任何他们想要的方式创造任何东西 - 走开。我已经处理了所有级别的客户和用户，并且有一件事情是可以保证的，即如果数据的有效和高效的设计使用户不感兴趣，并且因此通过剪切忽略将数据总是减少到一堆便便。

您需要设置一些边界，以便系统后面的数据存储保持一定的完整性。

来源

2010-09-01 04:42:44 drekka

是的，我关心的一件事是，如果我允许他们定义自己的表格，他们将把所有东西都捆绑在一张怪物表格中：[ – Alex 2010-09-01 04:51:09

我已经看到了，更糟。如果开发人员在单个表中存储包含财务数据的关系数据结构，并且字段名为Field1，Field2，Field3 ...都是String类型。雪地！我从头开始重新编写了整个应用程序，因为解开废话代码需要更多时间。哦，我被要求首先看这个程序的原因是大量的关键转换异常错误:-) – drekka 2010-09-01 05:14:31

+1“如果他们的客户要求能够以任何他们想要的方式创建任何东西 - 走开“。 - 如此真实！ – 2010-09-01 12:36:55

灵活的持久层

回答

相关问题