對於某個應用程序，我們捕獲某些表單數據。用戶可以隨意包含各個部分。關係數據庫中的自定義類型系統
每個部分需要捕獲的數據類型是每部分自定義的。有時他們是簡單的鍵值對詞典。有時它們包含具有一對多或多對多關係的子組件。雖然部分的數量可能會增加，但每個部分的模式都是已知的。
過去，表單部分是固定的，所以我們可以對每個部分的表結構進行硬編碼。我們沒有實現部分的通用方法 - 它是每個新部分的新數據訪問和表格。
但是，新的要求說，用戶應該能夠設計自己的部分。爲了避免動態操縱數據庫表，我們希望遷移到可以在數據中表示這些部分的高階模式。
如果數據只是單值字段的鍵值對，則可以使用Sections表和SectionFields表來實現。但是由於可能通過多值域和複雜類型的域來嵌套，我相信我們應該把它作爲一個基本的類型系統來處理。我不認爲它需要繼承。
我沒有重新從頭開始重新創建，而是假定已經在架構中完成了存儲在數據庫中的高效類型系統的工作。任何想法/指導？
謝謝。
Jason，
我不知道我理解你的問題。這是我從閱讀中收集的內容摘要：
您捕獲應用程序的表單數據。您的要求已更改爲允許用戶定義的部分。這對你來說很頭疼，因爲在關係型數據庫中，你必須動態地改變表以適應這個新的需求。
這可能是您使用錯誤工具進行工作的情況。關係數據庫非常適用於存儲和檢索具有良好建立關係的數據，但在數據中存在鬆散耦合關係或未定義關係時會非常糟糕。您可能會發現使用XML等技術可以更好地處理鬆耦合數據集的存儲。
對不起，如果這不是你要找的。這是我在StackOverflow上的第一篇回覆帖子，所以我仍然得到了這個問題。
祝你好運，
邁克爾
如果允許用戶創建自己的數據類型，那麼存儲它們的數據庫不再是關係數據庫。試圖以傳統方式存儲這些數據將會變得混亂。
您應該考慮將此數據存儲爲XML snippits。如果您可以構建支持用戶選擇的XML模式，並且您的數據庫支持XML數據類型（作爲較新版本的SQL Server），那麼您仍然可以對數據執行一些有用的查詢。
真的什麼OP所要求的是一個數據庫文件一樣蒙戈。由於OP可能不希望遷移到全新的持久性系統，因此無論您想要什麼，都可以使用XML，JSON將文檔存儲在SQL中。 –
@Spike Gronim - 我不熟悉Mongo，但它聽起來像你應該發佈一個單獨的答案。我認爲在回答這個問題時還有更多的想法。 –
雖然這些部分可以是用戶定義的，但它們在該用戶的應用程序中一直使用。 XML blob可能是要走的路。 –
嗨邁克爾，感謝您花時間回覆。我也在另一個答案中寫了這個 - 雖然這些部分可以是用戶定義的，但它們在該用戶的應用程序中一直使用。正如你所說，XML blob可能是要走的路。 –