在SQL中存儲用戶定義數據的正確方法

我想構建一個與wufoo非常類似的在線表單生成器，它允許用戶創建和發佈他們自己的Web表單。每次提交應保存到用戶以後可以檢索提交內容的數據庫中。在SQL中存儲用戶定義數據的正確方法

由於這些形式將是動態的，即。用戶可以完全控制表單字段的數量和類型，我試圖想到一個堅實的數據庫設計來存儲這些信息。

我會有一個表字段類型，其中包含用戶可用的每種類型的字段，即。文本框，emailfield等

將舉行各形式的ID只能有一個基本形式表，網址等

然後我會，其中將包括裁判的基本形式和字段類型的表formfields，該表還包括自定義驗證將在每個領域完成。

這種設計是否適合作爲基礎結構？我想，嚮應用程序添加新類型的字段會很容易，但我不知道潛在的缺點是什麼，因爲我離sql專家很遠。

2012-09-06 justinfay

在SQL

存儲用戶定義的數據，我認爲你正在尋找Entity–attribute–value數據庫模型，其中：

的基本思想是存儲屬性，及其相應的值，作爲單個表中的行。

通常情況下，表格至少有三列：實體，屬性和值。儘管如果只有一個相關實體，例如對於應用程序配置或選項設置，表可以排除實體列。

看到這個頁面作爲開始：

我重新標記您的問題與entity-attribute-value標籤，在其中你可以瀏覽很多與你的案例相關的線索。

2012-09-06 12:42:46

非常感謝您的回答entity-attribute-value恰恰就是我正在尋找的模型。 – justinfay

EAV被稱爲classis反模式... http://karwin.blogspot.com/2009/05/eav-fail.html您選擇了錯誤的路徑。 – Borys

@Borys - 你說得對，但是OP正在尋找一種方法來完成對錶單域數量和類型的完全控制。如何讓用戶能夠使用規範化的數據庫模型創建表單的字段和表單的類型，並且無法知道每個字段的屬性？它是動態的，你不能分辨出每個表單的列。 –

正如Mahmoud Gamal所寫，您描述的模型是「實體/屬性/值」;正如Borys寫道，這個模型存在許多已知的問題。

或者，您可以考慮將表單條目存儲在「文檔」中 - 例如， XML或JSON - 在關係模型中。

例如，你可能有沿的線表：

FORM_SUBMISSION 
-------------------- 
Submission_ID (pk) 
Client_ID (fk to clients table) 
Submission_date 
SubmissionDocument

我使用的「客戶」代表誰創建表單的用戶;要檢索給定客戶端的所有提交內容，請在client_id上使用where子句。

該模型使得對錶單提交運行SQL查詢變得更加困難（儘管當超出非常簡單的查詢時，EAV也變得很難），但它極大地簡化了持久性解決方案。

2013-08-10 10:33:37

謝謝你的答案Neville。 – justinfay

回答