灵活的持久层
我正在设计一个 ASP.NET MVC 2 应用程序。目前，我正在利用实体框架 4 和可切换的 SQLServer 和 MySQL 数据存储。
最近出现了一个要求，即应用程序允许操作用户定义的模型/实体。现在我不确定 SQL/关系数据库是否合适；例如，用户应该能够定义“员工”及其具有的属性，而不是添加/删除“员工”对象 - 在运行时有效地动态添加/删除表和列。
SQL 不适合这个吗？是否有选项可以让我保留在关系数据库结构中并仍然满足此要求？在实体框架内，我可以“即时”重新生成 .edmx 文件吗？或者是否有可以实现类似目标的替代方案？
我简要地了解了其他选项，例如“基于文档”的数据库和“无架构/无sql”数据库，例如 MongoDb。我还研究了一些序列化格式，例如 Google 的 Protocol Buffers、JSON 和 XML。根据您的经验，其中有哪些特别适合此目的？序列化性能并不是一个大问题。
该应用程序还处于起步阶段，我没有时间限制。本质上我可以随意重写它，所以如果废弃并重新开始是一个更好的选择，我对此非常开放。您有什么建议？提前致谢！
I am designing an ASP.NET MVC 2 application. Currently I am leveraging Entity Framework 4 with switchable SQLServer and MySQL datastores.
A requirement recently surfaced for the application to allow user-defined models/entities to be manipulated. Now I'm unsure if a SQL/relational database is appropriate at all; instead of adding/removing 'Employee' objects, for example, the user should be able to define an 'Employee' and what properties it has - effectively adding/removing tables and columns on the fly, at runtime.
Is SQL unsuitable for this? Are there options which allow me to stay within a relational database structure and still satisfy this requirement? Within the Entity Framework, can I regenerate .edmx files 'on the fly' or are there alternatives which achieve similar goals?
I've looked briefly at other options like 'document-based' dbs and 'schema-free/no-sql' dbs, such as MongoDb. I've also looked at some serialization formats such as Google's Protocol Buffers, JSON, and XML. From your experience, are any of these particularly suitable for this purpose? Serialization performance is not a big concern.
The application is in its infancy and I have no time constraints. Essentially I am free to rewrite it as I please, so if scrapping and starting over is a better alternative, I am very open to this. What are your suggestions? Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在查看选项之前，我建议（如果您还没有这样做:-）您需要明确定义用户将能够定义的内容。一旦掌握了这一点，您就可以推断出所需的灵活性级别以及完成这项工作所需的数据存储类型。
另一条建议是，如果客户要求能够以任何他们想要的方式创造任何东西，那就走开。我与各个级别的客户和用户打过交道，可以保证的一件事是，用户对有效且高效的数据设计不感兴趣，因此总是会通过剪切忽略将数据减少为一堆粪便。
您需要设置一些边界，以便系统背后的数据存储保持一定的完整性。
Before looking at options I'd suggest (if you have not already done it :-) that you need to get a clear definition of exactly what users will be able to define. Once you have that you can then deduce an idea of the level of flexibility needed and therefore the type of data store needed to do the job.
One other word of advice would be that if they clients demand to be able to create anything any way they want - walk away. I've dealt with clients and users at all levels and one thing that is guaranteed is is that users have no interest if the effective and efficient design of data and therefore will always reduce the data to a pile of poo through shear neglect.
You need to set some boundaries so that the data store behind the system maintains some integrity.