大型表单和文档数据库是否合适？答案

【问题标题】：Are large forms and document databases a good match?大型表单和文档数据库是否合适？
【发布时间】：2011-04-19 18:03:42
【问题描述】：

我继承了用 PHP 处理的超大型 Web 表单的支持。我在 PHP 开发方面经验丰富，但原作者不是。目前数据保存在关系数据库中，但我正在考虑切换到文档数据库（尤其是 mongodb），并且想知道这个用例是否适合文档数据库。

====目前的情况====

大约有 1400 个表单元素（是的，您没看错）分布在用户界面的多个选项卡中。表单元素名称一对一映射到数据库中的列。出于某种原因，它跨越了 4 个数据库表。可能mysql对列数有限制。我已经极大地重构了数据保存，但是查询后端很痛苦。

此表单的部分用例是一个人每年都会填写它。当表格被“打开”时，前一年的数据被向前复制。这样他们就不必重新输入保持不变的东西。对于大多数人来说，他们只需要一小部分表单字段。大约有 25 个地方可以让人们上传文件而不是直接输入数据。此表单的访问量不大。

关于它的最丑陋的事情之一是表单空间是如何分配的。如果您有 10 个“foo”元素，那么您在数据库中有 10 个列，称为 foo1、foo2 等。需要第 11 个吗？向数据库添加一列，编辑 html 和 PHP。插科打诨。哦，是的，请确保对可打印版本也这样做。

当前的设计没有使用关系。我没有性能问题，但管理起来很麻烦，而且像这样存储/检索数据只是“感觉不对”。

==== 丢弃的解决方案 ====

有一段时间我考虑制作一个合适的关系表，这样我就可以在不改变数据库架构或表单的情况下拥有我的第 11 个“foo”表单元素。当我把它绘制出来时，ER 图变得有点压倒性。我的直觉说这是对架构的改进，但必须有一个更简单的解决方案。

==== 建议的解决方案 ====

所以，我建议编写一个脚本来将数据移植到 mongodb 存储中，然后开始从中写入/读取。它仍然会有大量的字段，但数据管理似乎更明智。如果我想要第 11 个 'foo'，我只需存储它。如果存在数据层次结构，则都在一个地方。

这里有什么我应该注意的陷阱吗？人们会推荐其他方法吗？

【问题讨论】：

您可能希望通过首先弄清楚您需要如何处理数据来解决这个问题。会被搜索到吗？如果是这样，怎么做？它将如何被操纵？这些数据是否由其他系统共享？这可以帮助您决定可能要使用的格式和数据库系统。
好点，KTF。为简洁起见，我省略了一些细节，但数据的搜索需求非常有限。它不会馈送到其他系统。它几乎就像你能得到的纸质表格一样。它不是完全“存储并忘记”，但它是关闭的，因为在保存和读取后它很少被引用。

【解决方案1】：

这个问题与 RDBMS 与 NoSQL 无关 - 每个适当设计的后端数据库层都可以处理这样的问题。在 ORM 的世界中，灵活应对不断变化的数据库需求和复杂的数据库模式是相当容易的。这同样适用于 NoSQL 数据库——尽管它们通常没有模式。不管怎样，你的意思是什么？

【讨论】：

我认为他正在就他提出的解决方案征求意见，并看看是否有人从经验中获得任何关于最容易使用/维护的信息......但是，这通常取决于许多人因素，并且对他可能正在使用的系统非常具体......
RestRisiko，在废弃的方法中，我开始使用 symfony 1.3 和 Doctrine 作为 ORM 来重建它。我在使用各种 ORM 工具（adodb、pdo、教义、推进）方面拥有丰富的经验，而且似乎我正在创造一种新的复杂性，走规范化的关系路线。我知道 RDBMS 可以工作，但是因为文档数据库对我来说有点新，所以我很好奇我的用例是否合理。
我会在很长一段时间后返回这个问题，并且对这种情况有更多经验，看到@Blaackmoon 是正确的，这与数据库机制无关。