2011-04-19 50 views
1

我已经继承了PHP中处理的非常大的Web表单的支持。我在PHP开发方面经验丰富,但原作者并非如此。目前,数据保存在关系数据库中,但我正在考虑切换到文档数据库(特别是mongodb),并且有兴趣知道这个用例是否与文档数据库的匹配良好。大型表单和文档数据库是否匹配?

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

大约有1400表单元素(是的,你没看错)在用户界面中的几个选项卡蔓延。表单元素名称与数据库中的列一对一映射。出于某种原因,它跨越了4个数据库表。可能mysql对列数有限制。我已经大幅度地重构了数据保存,但是查询后端却很痛苦。

这种形式的用例的一部分是每年都有人填写它。当表格被“打开”时,前一年的数据被向前复制。通过这种方式,他们不必重新输入保持不变的东西。对于大多数人来说,他们只需要一小部分表单域。大约有25个地方可以上传文件来代替直接输入数据。这种形式不会造成交通繁忙。

最丑陋的事情之一是如何分配表单空间。如果你有10个'foo'元素,那么你在数据库里有10个列叫做foo1,foo2等。需要第11个?添加一列到数据库,编辑HTML和PHP。插科打诨。哦,是的,一定要为可打印版本做同样的事情。

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

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

有一段时间我认为做一个适当的关系表,这样我可以有我11“富”表单元素,而不改变DB模式或形式。当我将它映射出来时,ER图变得有点压倒性。我的直觉说这是对建筑的改进,但必须有一个更简单的解决方案。

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

所以,我建议转移到MongoDB的商店编写一个脚本来港的数据,并开始写/从中读取代替。它仍然有大量的领域,但数据管理似乎更明智。如果我想要第11个'foo',我只是把它存储起来。如果有一个数据层次结构,它就在一个地方。

我在这里应该注意哪些缺陷?人们会推荐其他方法吗?

+0

您可能需要先了解您需要如何处理数据。它会被搜索吗?如果是这样,怎么样?它将如何被操纵?这些数据是否由其他系统共享?这可能会帮助您决定可能要使用的格式和数据库系统。 – KTF 2011-04-19 18:13:41

+0

好点,KTF。为了简洁起见,我留下了一些细节,但数据的搜索需求非常有限。它不会进入其他系统。就像你可以得到的那样,它就像纸质表格一样接近。它并不完全是“存储和遗忘”,但它很接近,因为在它被保存并阅读之后,它很少被引用。 – 2011-04-21 12:27:53

回答

1

这个问题与RDBMS与NoSQL无关 - 每个设计合适的后端数据库层都可以处理这样的问题。在ORM的世界中,通过改变数据库要求和复杂的数据库原理图可以很灵活地实现灵活性。这同样适用于NoSQL数据库 - 尽管它们通常没有模式。无论如何,你有什么意思?

+0

我认为他要求他提出的解决方案的输入,并且看看是否有人从经验中得到任何有关可能最容易使用/维护的信息...但是,这通常取决于许多因素,并且对于系统他可能正在... – KTF 2011-04-19 18:12:05

+0

RestRisiko,在被遗弃的方法中,我开始使用symfony 1.3和Doctrine作为ORM重建它。我在使用各种ORM工具(adodb,pdo,doctrine,propel)方面拥有丰富的经验,看起来我正在创建一种新的复杂性,使得规范化的关系路线成为可能。我知道RDBMS可以工作,但由于文档数据库对我来说有点新奇,如果我的用例听起来合理,我很好奇。 – 2011-04-21 12:30:57

+0

我在很长一段时间后回过头来,并且对这种情况有了更多的经验,请参阅@Blaackmoon是正确的,这与数据库机制无关。 – 2012-02-10 14:33:24