架構設計時，用戶可以自定義字段

我試圖想出一個應用程序，允許用戶創建調查，並提交給公衆最好的數據庫模式。大多數調查（但不是全部）都會包含一系列「標準」人口統計字段，例如名字，姓氏等。當然，用戶可以創建無限數量的「自定義」問題。

我想到的第一件事情是這樣的：

Survey 
    ID 
    SurveyName 

SurveyQuestions 
    SurveyID 
    Question 

Responses 
    SurveyID 
    SubmitTime 

ResponseAnswers 
    SurveyID 
    Question 
    Answer

但是，這是怎麼回事我想查詢出來的數據，每次吸。它似乎危險地接近Inner Platform Effect

的改進將包括儘可能多的領域，我可以事先在響應表認爲：

Responses 
    SurveyID 
    SubmitTime 
    FirstName 
    LastName 
    Birthdate 
    [...]

然後從這些公共列至少查詢的數據直截了當，並且我可以查詢，例如，曾經回答任何調查問卷的人的平均年齡。

但似乎這樣會使代碼複雜一點。現在要查看調查中詢問哪些問題，我必須檢查哪些常見響應字段已啓用（我猜測，使用Survey中的一個位域）以及SurveyQuestions表中的內容。而且我不得不擔心特殊情況，例如有人試圖在「答覆」表中創建一個重複「常見」問題的「自定義」問題。

這是我能做的最好的嗎？我錯過了什麼嗎？

來源

2009-01-09 Eli

我可以建議將您的問題的標題更改爲「什麼是調查系統的最佳數據庫模式？」 – 2009-01-09 20:29:28

您的第一個模式是兩者中較好的選擇。此時，您不應該擔心性能問題。擔心做出一個好的，靈活的，可擴展的設計。您稍後可以使用各種技巧來緩存數據並加快查詢速度。使用不太靈活的數據庫模式來解決甚至可能無法實現的性能問題是一個不好的決定。此外，很多（也許是大多數）調查結果只能定期查看，並且只有少數人（活動組織者，管理員等）查看，所以您不會經常查詢數據庫中的所有結果。即使你是，表現也會很好。無論如何，你可能會以某種方式對結果進行分頁。

第一個模式更加靈活。默認情況下，您可以包括名稱和地址等問題，但對於匿名調查，您可以根本不創建它們。如果調查創建者只想查看每個人對五百個問題中三個問題的答案，那麼這是一個非常簡單的SQL查詢。您可以設置級聯刪除，以在調查被刪除時自動刪除回覆和問題。使用此架構生成統計信息也會更容易。

以下是您提供的模式的略微修改版本。我想你可以找出哪些數據類型去哪裏:-)

 
    surveys 
     survey_id (index) 
     title 

    questions 
     question_id (index, auto increment) 
     survey_id (link to surveys->survey_id) 
     question 

    responses 
     response_id (index, auto increment) 
     survey_id (link to surveys->survey_id) 
     submit_time 

    answers 
     answer_id (index, auto increment) 
     question_id (link to questions-question_id) 
     answer

來源

2009-01-09 20:23:39

我建議你總是採用規範化的方法處理數據庫模式，然後再決定是否需要爲性能原因創建解決方案。過早優化可能是危險的。過早的數據庫去歸一化可能是災難性的！

我建議你堅持使用原始模式，如果有必要，稍後創建一個報表，它是規範化模式的非標準化版本。

來源

2009-01-09 19:59:08

可能或不可能幫助簡化事情的一個變化是不將ResponseAnswers鏈接回SurveyID。而是爲每個回答和每個問題創建一個ID，並讓您的ResponseAnswers表包含字段ResponseID，QuestionID，Answer。雖然這將需要爲每個單元保留唯一的標識符，這將有助於使事情更加標準化。答案答案不需要與他們回答的調查相關聯，而只是回答他們正在回答的具體問題以及他們相關的答覆信息。

來源

2009-01-09 20:08:56 Bill

是的，這是有道理的。 – Eli 2009-01-09 20:16:19

我在以前的工作中創建了一個客戶調查系統，並提出了一個與您擁有的模式非常相似的模式。它被用來發送調查（在紙上）並列出響應。

一對夫婦的細微差別：

調查是不是匿名，這被做在印製的表格非常清楚。這也意味着您的示例中的人口統計數據是事先知道的。
由於調查中附帶了一系列問題，因此可以在多個調查中使用一個問題，並獨立於其出現的調查進行分析。
處理不同類型的問題變得有趣 - 我們有1-3個等級（例如，更差/相同/更好），1-5個等級（非常差，差，OK，良好，非常好），是/否和評論。

有特殊的代碼來處理評論，但其他問題類型的處理一般是有一個問題類型表和每個類型的有效答案的另一個表。

爲了使查詢更容易，您可以創建一個函數，根據調查ID和問題ID返回響應。

來源

2009-01-09 20:11:16 Dave

好點。是的，我忽略了處理不同類型的問題以專注於我的文章，但我必須解決這些問題，並支持用戶定義的驗證規則。 – Eli 2009-01-09 20:14:51

架構設計時，用戶可以自定義字段

回答

相關問題