數據庫模式的建議值

我一直在負責創建一個應用程序，允許用戶將數據輸入到將被保存並最終用於填充PDF表單域網絡形式的能力。數據庫模式的建議值

遇到麻煩試圖想存儲在數據庫中的字段值的形式將是動態的好方法（基於PDF場）。

的應用程序本身我將圍繞傳遞數據的哈希表（字段名，fieldValue方法），但我不知道該散列轉換爲分貝值的最佳方式。

我正在使用MS SQL Server 2000和asp.net webforms。有沒有人有過類似的工作？

2011-11-18 pteranodonjohn

也許你可以分享一些領域和與我們的關係。有時候，這實際上取決於目的，所以表格必須進行標準化，有時候，我們必須對錶格進行非規範化處理（例如在倉儲的某些情況下）！:) – Nonym

我仍處於設計的最初階段，所以沒有任何東西以任何方式完成。很可能，正如下面的gview所建議的那樣，我將有一個Form表格，用於存儲諸如表單類型，created_on等列......表單表格與FormField表具有一對多的關係，存儲字段名稱，類型和價值。 – pteranodonjohn

只是想補充說，這是一個保險後臺辦公類型的應用程序。字段值將保存諸如駕駛執照號碼之類的信息以解決字段。 – pteranodonjohn

你有沒有考慮過在這裏使用文檔數據庫？這只是他們解決的問題，比傳統的RDBMS解決方案好得多。就我個人而言，我是RavenDb的忠實粉絲。另一個相當不錯的選擇是CouchDb。我會避免使用MongoDb，因爲它在當前的實現中確實不是數據安全的地方。

即使你不能使用文檔數據庫，就可以使SQL假裝通過設置你的表有與有效載荷字段是序列化XML或JSON傳統列的一些元數據是一個。這將允許您在EAV-land外出時搜索元數據。 EAV-land是一個可怕的地方。

UPDATE

我不知道，如果一個很好的指導存在，但概念是非常簡單的。基本思想是將你想查詢的部分分解成表格中的「普通」列 - 這可以讓你以標準方式進行查詢。當你找到你想要的記錄時，你可以抓住CLOB並將其反序列化。你的情況，你會看起來像一個表：

SurveyAnswers 
    Id INT IDENTITY 
    FormId INT 
    SubmittedBy VARCHAR(255) 
    SubmittedAt DATETIME 
    FormData TEXT

幾個protips：
一）使用基於文本的序列程序。給你一個解決數據錯誤的戰鬥機會，真正幫助調試。
b）對於SQL 2000，您可能需要考慮將CLOB（包含有效負載數據的TEXT字段）分解到單獨的表中。自從我使用SQL 2000以來，它已經很長時間了，但是我的回憶是使用TEXT列對錶格做了不好的事情。

來源

2011-11-18 19:29:11

我真的很喜歡這個想法。我希望將信息存儲在json或xml中，但我對數據庫存儲非常有限。基本上堅持與MS SQL SERVER 2000.你能提供一些方向，我可以找到在列中使用元數據的文檔？ – pteranodonjohn

只是擴大了答案，我在基於Sql 2000的應用程序FWIW上非常成功地使用了它。 –

我建議鏡像相同的結構：

Form 
----- 
form_id 
User 
created 

FormField 
------- 
formField_id 
form_id 
name 
value

來源

2011-11-18 18:59:21 gview

爲你所描述的所謂Entity Attribute Value（EAV），該模型可以是一個皇家疼痛處理解決方案。所以你應該儘可能地限制你對此的使用。

例如是否有字段幾乎總是在形式（姓，名，電子郵件等），那麼你應該把它們放在一個表作爲字段。

這樣做的原因是因爲如果不這樣做別人遲早會認識到，他們有這些名字和電子郵件，並要求你建立這個查詢

 SELECT 
     Fname.value fname, 
     LName.Value lname, 
     email.Value email, 
     .... 
    FROM 
     form f 
     INNER JOIN formFields fname 
     ON f.FormId = ff.FormID 
      and AttributeName = 'fname'  
     INNER JOIN formFields lname 
     ON f.FormId = ff.FormID 
      and AttributeName = 'lname' 
     INNER JOIN formFields email 
     ON f.FormId = ff.FormID 
      and AttributeName = 'email' 
     ....

時，你可以寫這

SELECT 
     common.fname, 
     common.lname, 
     common.email, 
     .... 
    FROM 
     form f 
     INNER JOIN common c 
     on f.FormId = c.FormId

而且只要你可以下車SQL 2000的，因爲你要真的很懷念UNPIVOT條款

它也p robably不是一個壞主意，看看以前的SO EAV questions給你一個人們遇到過的問題的想法

來源

2011-11-18 19:20:13

感謝您的輸入，我一定會研究EAV。我希望我能夠脫離SQL 2000，但是恐怕很長一段時間會讓我留在那裏。 – pteranodonjohn

數據庫模式的建議值

回答

相關問題