2011-04-19 20 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

相關問題