我继承了在PHP中处理的非常大的Web表单的支持。我在PHP开发方面经验丰富，但原作者却没有。目前数据存在于关系数据库中，但我正在考虑切换到文档数据库（特别是mongodb），并且有兴趣知道这个用例是否听起来像是文档数据库的良好匹配。
====当前情况====
大约有1400个表单元素（是的，您正确阅读）分布在用户界面中的多个选项卡上。表单元素名称与数据库中的列一对一映射。出于某种原因，它跨越4个数据库表。可能mysql对列数有限制。我已经大幅度地重构了数据，但查询后端是一件痛苦的事。
此表单的部分用例是每个人每年填写一次。当表格“打开”时，前一年的数据被向前复制。通过这种方式，他们不必重新输入保持不变的东西。对于大多数人来说，他们只需要一小部分表单字段。大约有25个地方，一个人可以上传文件，而不是直接输入数据。这种形式不会带来繁重的流量。
最丑陋的事情之一是如何分配表单空间。如果你有10个'foo'元素，你在数据库中有10个名为foo1，foo2等的列。需要第11个？在db中添加一列，编辑html和PHP。插科打诨。哦，是的，请确保对可打印版本也这样做。
目前的设计没有使用关系。我没有性能问题，但管理起来很麻烦，存储/检索这样的数据“感觉不对”。
====废弃解决方案====
有一段时间我考虑制作一个合适的关系表，这样我就可以拥有我的第11个'foo'表单元素，而无需更改db模式或表单。当我绘制出来时，ER图变得有点压倒性。我的直觉说这是架构方面的改进，但必须有一个更简单的解决方案。
====建议的解决方案====
所以，我建议编写一个脚本将数据移植到mongodb商店，然后开始写入/读取它。它仍然会有大量的字段，但数据管理似乎更明智。如果我想要第11个'foo'，我只需存储它。如果存在数据层次结构，则它们都在一个地方。
我在这里应该注意哪些陷阱？人们会推荐其他方法吗？
答案 0 :(得分：1)
这个问题与RDBMS与NoSQL无关 - 每个正确设计的后端数据库层都可以处理这样的问题。在ORM的世界中，通过改变数据库需求和复杂的数据库模式可以非常灵活。这同样适用于NoSQL数据库 - 尽管它们通常没有架构。无论如何，你的观点是什么？