我已经继承了PHP中处理的非常大的Web表单的支持。我在PHP开发方面经验丰富,但原作者并非如此。目前,数据保存在关系数据库中,但我正在考虑切换到文档数据库(特别是mongodb),并且有兴趣知道这个用例是否与文档数据库的匹配良好。大型表单和文档数据库是否匹配?
====目前的情况====
大约有1400表单元素(是的,你没看错)在用户界面中的几个选项卡蔓延。表单元素名称与数据库中的列一对一映射。出于某种原因,它跨越了4个数据库表。可能mysql对列数有限制。我已经大幅度地重构了数据保存,但是查询后端却很痛苦。
这种形式的用例的一部分是每年都有人填写它。当表格被“打开”时,前一年的数据被向前复制。通过这种方式,他们不必重新输入保持不变的东西。对于大多数人来说,他们只需要一小部分表单域。大约有25个地方可以上传文件来代替直接输入数据。这种形式不会造成交通繁忙。
最丑陋的事情之一是如何分配表单空间。如果你有10个'foo'元素,那么你在数据库里有10个列叫做foo1,foo2等。需要第11个?添加一列到数据库,编辑HTML和PHP。插科打诨。哦,是的,一定要为可打印版本做同样的事情。
当前的设计没有使用关系。我没有性能方面的担忧,但管理起来很麻烦,而且像这样存储/检索数据只是“感觉不对”。
====丢弃的解决方案====
有一段时间我认为做一个适当的关系表,这样我可以有我11“富”表单元素,而不改变DB模式或形式。当我将它映射出来时,ER图变得有点压倒性。我的直觉说这是对建筑的改进,但必须有一个更简单的解决方案。
====建议的解决方案====
所以,我建议转移到MongoDB的商店编写一个脚本来港的数据,并开始写/从中读取代替。它仍然有大量的领域,但数据管理似乎更明智。如果我想要第11个'foo',我只是把它存储起来。如果有一个数据层次结构,它就在一个地方。
我在这里应该注意哪些缺陷?人们会推荐其他方法吗?
您可能需要先了解您需要如何处理数据。它会被搜索吗?如果是这样,怎么样?它将如何被操纵?这些数据是否由其他系统共享?这可能会帮助您决定可能要使用的格式和数据库系统。 – KTF 2011-04-19 18:13:41
好点,KTF。为了简洁起见,我留下了一些细节,但数据的搜索需求非常有限。它不会进入其他系统。就像你可以得到的那样,它就像纸质表格一样接近。它并不完全是“存储和遗忘”,但它很接近,因为在它被保存并阅读之后,它很少被引用。 – 2011-04-21 12:27:53