對於所有與一個數據項有關係的表的不同架構設計的優缺點

我正在開發一個將具有數據庫後端的系統。我打算每個表都有一個任意的PK，系統生成和維護。對於所有與一個數據項有關係的表的不同架構設計的優缺點

我的環境（用於開發和生產）是Windows 7;德爾福;和一個嵌入式數據庫（可能是Firebird）。

我的數據結構包括一個表的所有者，具有與之相關聯的信息非常少 - 可能不超過名稱和說明等等。數據結構的其餘部分大約有50個表格，每個表格都有名稱和說明，以及其他屬性列表 - 每個表格平均說20個。另外，可能有20個關聯表，其中大多數將只具有FK屬性，儘管一小部分將具有附加屬性。我的意圖是（至少從頭開始）使模式完全標準化。

對於給定的所有者，大多數表將有O（10^3至10^4）記錄，雖然一個或兩個將具有O（10^5至10^6）。 OWNER的數量可能是O（10^2到10^3）。大多數訪問可能會聚集在一起 - 一個OWNER會有相當多的訪問，然後是另一個OWNER訪問的大量訪問。

每個數據項屬於一個所有者，並且不能從業主移交使用。對數據庫的所有訪問都將知道他們正在使用的是OWNER;任何訪問都無法訪問多個OWNER的內容。

我知道在我的設計架構中的以下三個選項：

描述使用主表。在每個表中使用OWNER PK作爲外鍵（儘管可能不是關聯表）。添加OWNER PK作爲附加條款到每一個查詢，連接，存儲的過程，查看等
添加列含有一個小代碼僱主表 - 說四位數整數。對於每個OWNER，創建一組重複的表 - 特定OWNER的表名將添加相應的代碼作爲後綴。這將要求每個訪問先前都從數據庫中獲得後綴代碼。然後訪問將是相關的一組表格。
對於每個OWNER，創建一個重複的數據庫，並重復表和表名。這意味着可能會有一個輔助公用數據庫，其中包含有關相關重複數據庫的數據。同樣，這個公共數據庫需要在任何訪問之前訪問 - 或者對一個特定的OWNER進行一系列訪問。

什麼是這些不同方法的利弊？我錯過了整體設計的其他選擇嗎？

編輯逆轉 - 我提供我自己的答案，而不是。

來源

2011-02-06 Chris Walton

我沒有看到任何錯誤，因爲它是。有些問題很難精確地表達清楚。我認爲爲簡潔起見編輯這隻會增加混淆。由於它已被投票，並且至少有一個投票答案，社區發現它的一些價值:) –

@Tim =謝謝你迴應我的國旗。 –

沒有「完全正常化的標準形式」這樣的東西。 –

選項＃1是迄今爲止最好的。顯然你打算使用一個系統生成的id號碼來記錄這個記錄......否則如果你的OWNER pk是這個人的名字，並且你最終得到了多個John Smith，那麼你將遇到一個問題。

選項＃2可以正常工作，但會增加太多的複雜性。只要你已經擁有OwnerId作爲OWNER表中的PK，那麼對於剩下的就可以節省額外的開銷和努力。

選項＃3。如果您的前端界面很差，並希望能夠通過手動方式輕鬆讀取記錄並理解它們，此選項非常有用。但是所有額外的表格會減慢你的速度並創建額外的子程序，這些子程序必須寫入前端以跟蹤表格。

來源

2011-02-06 04:58:02 techtheatre

我的觀點是1是最複雜的 - 連接和意見至少在3個表之間;每個存儲過程至少有2個表 - 所有這些都使維護，構建和測試變得更加複雜。對於2我打算使用表名作爲參數。這需要一些額外的小例程 - 表名的getter和setter。你認爲必要的額外開銷和努力是什麼？ 3也會有一個參數 - 數據庫名稱 - 爲什麼前端需要額外的子例程 - 每個OWNER的表名都是相同的？ –

謝謝 - 您的回覆讓我想到了這個問題的不同方面。這個進一步的想法讓我得到了下面給出的答案。 –

繼續思考這個問題，根據@ techtheatre的回答，我意識到對模式的任何更改都意味着對選項2或3運行更改腳本1000次。這顯然不明智。

來源

2011-02-06 15:49:30

對於所有與一個數據項有關係的表的不同架構設計的優缺點

回答

相關問題