我已經繼承了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