2009-12-01 20 views
1

在處理將存儲大量(完全不同)表單的項目時,我正面臨着如何在保持數據庫可用的同時存儲值的設計問題。在DBMS中存儲動態表單數據,尋找最佳方法

簡要說明:每個'文檔'包含可變數量的問題(儘管每種文檔類型的數量一致)和匹配答案。

我提出的最實用的方法如下,在這裏我用'type'對文檔進行了分組,這些文檔標識哪些問題屬於文檔,哪些是問題的答案。

+---------------+ 1  n +-----------+ 
    | DocumentType |----------| Questions | 
    +---------------+ Has many +-----------+ 
     |1      1| 
     |n Is of type   n| Belongs to 
    +---------------+ 1  n +-----------+ 
    | DocumentEntry |----------| Answers | 
    +---------------+ Has many +-----------+ 

的這裏的缺點是,查詢獲取上有質疑與應答b變得相當複雜,當數據庫變得很大可能相當緩慢的文件,它會很快。

我想知道是否偶然發現了存儲數據的最佳方法,或者是否存在我可能錯過的一些簡潔解決方案。

回答

2

您遇到了一個常見問題:嘗試使用某些靜態(具有預定義結構的數據庫)的某些動態(一組單個數據集只有一個共同點:它們來自表單)。你想要的是可行與數據庫,但會顯著更加容易,而不做,但因爲我認爲你確實要使用這個數據庫,這裏就是我想要做的:

  • 你有document (或問卷)其中包含多個questions。這些都足夠通用並且需要自己的表格,就像您迄今爲止所做的一樣。
  • 每個問題有一個type它定義了它是什麼樣的問題(多選,自由格式,選擇一個...),當然這個問題也有options。那就是兩張表格。這裏的推理是,將這些與實際問題分離可以實現某種程度的抽象,並且儘管可能存在問題,但查詢仍然會有點簡單。

因此,每個文件有1..n個問題,每個問題有1個類型和1..n個選項。跳過了一下,這裏就是我想的與鏈接表等

Document 
    bigint id 
DocumentQuestions 
    bigint document_id 
    bigint question_id 
Question 
    bigint id 
    varchar question 
QuestionType 
    bigint question_id 
    bigint type_id 
Type [pre-filled table with id:type pairs, such as 1=freeform, 2=select one etc.] 
QuestionOptions 
    bigint id 
    bigint question_id 
    varchar description 
    varchar value 

Answers 
    bigint id 
    bigint document_id 
    [etc. such as user_id] 
QuestionAnswers 
    bigint answer_id 
    bigint question_id 
    bigint questionoptions_id 

這類設計允許幾件事情:

  • 問題本身,如果你正在做可重複使用,非常方便的一個通用「回答這些來自y個問題池的隨機問題」。
  • 新類型可以輕鬆添加,而不會破壞現有的類型。
  • 您可以隨時輕鬆瀏覽結構,例如「這個單個問題答案的文檔名稱是什麼?」或「有多少人對此問題的回答不正確?」
  • 因爲類型是分開的,所以可以創建一個反映數據庫中狀態的(web)UI - 更好的是,如果類型發生變化,您甚至可能根本不需要觸摸UI代碼。
  • 由於每個問題的可能選項都是QuestionOptions表中的自己的行,因此可以非常輕鬆地獲得實際值。

這個問題顯而易見,它需要表格之間的完整性相當嚴格的耦合,並且在開始時會很痛苦地正常運行。另外由於QuestionOptions中的value是varchar,因此您需要能夠解析很多東西,甚至可能需要爲轉換提示引入另一個字段。

希望這會有所幫助,即使您完全不同意我的解決方案。

+0

非常感謝您的快速輸入,我很高興閱讀您對我的問題的解釋,這應該已經相當具體一些,沒有我的結局。 解答答案和'答案類型'確實是一個很好的建議,遺憾的是,我應該提到在這裏假設所有答案都是簡單的變量在這種情況下是安全的,沒有其他類型存在。 Upvoted對於你已經給出這個問題的明顯數量的想法,將接受它作爲解決方案,除非有其他人出現 - 非常感謝。 – Leftblank

+0

謝謝。然後等待一段時間,然後才能接受,這樣其他人可能仍然會回答,因爲我不完全確定所有SO的數據庫巫師在這個小時都醒了。哦,我之前做過類似的事情,這基本上是我當時的做法 - 這也是第一段中警告的來源,通過使用完全專有的解決方案報廢數據庫,我們看到** 28 000%* *在這個系統中使用類似的東西的性能增加(*不是用於問題,而是類似的結構*)。 – Esko

+0

可能不完全相關,但我很好奇這個解決方案是什麼,你介意分享所使用的專有解決方案的名稱/類型嗎?謝謝! – Leftblank

相關問題