php - 大型表格和文档数据库是否匹配？

Question

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

====现状====

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

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

关于它的最丑陋的事情之一是表格空间的分配方式。如果你有 10 个 'foo' 元素，你在数据库中有 10 列，称为 foo1、foo2 等。需要第 11 列吗？向数据库添加一列，编辑 html 和 PHP。插科打诨。哦，是的，请确保对可打印版本也执行相同的操作。

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

====废弃的解决方案====

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

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

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

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

Answer 1

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