关于将MongoDB与/ MySQL混合用于Web应用程序的建议

时间:2012-01-20 02:31:55

标签: mysql mongodb normalization rdbms nosql

我有一个使用关系数据库(MySQL)的Web应用程序。我们正在添加一项新功能,允许某些用户从可选表单元素池中动态构建“表单”,并将这些表单分发给其他用户完成/提交。

问题在于存储已完成的表单提交。每个表单可以并且将在表单元素的数量和组合方面有所不同,并且对于关系数据库,我的选项在某种程度上局限于动态创建一个新表来保存每个表单的提交(似乎是一个不好的路径)或存储每个提交的表单作为TEXT列中的JSON(丢失了所有有用的RDBMS查询功能)

我以前从未在生产项目中实际使用过MongoDB,但我认为使用我的MySQL关系数据库来存储我的应用程序的某些用户创建的所有表单,然后存储所有表格可能是一个好主意。 MongoDB中的提交,每个文档引用MySQL中表单的UUID。

我能用这种方法思考的第一个缺点是表单提交和MySQL中的表单之间没有引用完整性。如果我在MySQL中删除表单,则必须手动删除所有表单提交(如果我想复制'Cascade'效果)

我是否会将单个MongoDB集合中所有表单的所有表单提交存储为单独的文档?任何意见是极大的赞赏。 :)


编辑1 根据此处的文档:http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

我现在正在考虑创建一个新的集合来保存每个唯一表单类型的所有提交。


编辑2

经过一些仔细的考虑和其他人的建议后,我决定放弃我的双数据库方法来解决这个问题,转而采用关系数据库模式,我认为这解决了创建动态表单和保存表单提交的问题。以这种方式,他们很容易查询复杂的报告。

enter image description here

基本上,“表单”中的每个记录都代表一个由用户构建的唯一表单。 'forms_fields'有一个引用表单的外键和一个带有选项的枚举类型: 1.复选框 文本字段 3. textarea 4.选择 5.多选 6.日期

'forms_fields_options'包含选择字段所具有的所有“选项”。 通过这三个表,用户可以创建自定义表单。

当另一个用户填写&提交表单,在forms_submissions中创建一条记录。对于每个字段,将在'forms_submissions_fields'中创建相应的记录,该记录引用表单提交和forms_fields_id。最终表'forms_submissions_options_multiselect'本质上是一个连接表,用于指示用户选择的多选表单字段中的哪些选项。

3 个答案:

答案 0 :(得分:7)

我的一位同事最近主持了一个关于这个主题的网络研讨会,名为“与MongoDB和RDBMS的混合应用程序”。你可以在这里查看: http://www.10gen.com/events/hybrid-applications

从评论中看来,您似乎已经决定采用RDBMS路线,但希望这可以为您提供未来项目的一些想法,或者对阅读此线程的其他人有益。

祝你的申请顺利!

答案 1 :(得分:3)

这绝对可以使用EAV在SQL中完成。所以NoSQL肯定不是必需的。

使用像MongoDB这样的工具可能非常适合您想要保存的灵活结果,但是,这里有一些权衡取舍,但它们可能并不完全符合您的期望。

  

...将每个提交的表单作为JSON存储在TEXT列中( 丢失所有有用的RDBMS查询功能

您计划提交多少份表单?你打算做什么类型的查询?

我对MongoDB的体验是,当您查询未编制索引的数据时,它的性能非常差。此外,聚合通常使用Map / Reduce(或新的聚合框架)批量完成。

如果比较进行汇总的复杂性或进行查询的效率,那么目前尚不清楚MongoDB在这方面明显优于EAV。

  

如果我在MySQL中删除表单,则必须手动删除所有表单提交

奇怪的是,我很少将此视为一个问题,因为您可能永远不会删除SQL中的表单。你可能会做一个逻辑删除,从来没有真正删除任何东西。所以这可能是一个有争议的问题。

  

我是否会将单个MongoDB集合中所有表单的所有表单提交存储为单独的文档?

再次取决于您计划获得多少表格和提交。如果你有很多,那么使用收集/提交将很难在以后进行分类。

老实说,我会使用单个集合,然后将_id字段覆盖为可以合理地用作分片键的字段。你可以在这里玩一些花哨的技巧,但这超出了这个小写的范围。

摘要

当天结束时,你肯定可以使用MongoDB来解决这个问题,但这不是“本垒打”。如果您不熟悉MongoDB,这绝对是一个公平的“学习项目”,但期望在查询和聚合方面遇到一些障碍。

答案 2 :(得分:1)

我认为你忽略了一个事实,即RDBMS会允许像EAV(实体 - 属性 - 价值,如果你过度使用它,但可以很好地适度)或连接表,构建多个有序关系从单一形式到各种形式元素。

我并不是说RDBMS对于所有事情,甚至是你的情况都是完美的,但我知道我必须建立类似的系统,并且从来没有必须以合理的方式使用noSQL来支持它们。

编辑:更重要的是......存储实际字段值会使您与原始表单元素之间的关系更多,但如果您的UI保持一致,则可以执行此操作。我想进一步研究哪些noSQL解决方案允许你需要的特定类型的基于价值的查询可能会更多地说明你的选择。