什麼時候DB表應該分成兩個單獨的表？

我有一個用戶表，它使用單表繼承，這樣我可以在同一個表中同時擁有顧問，客戶和內部用戶。我想爲「筆記」創建一個表格，以便內部用戶可以爲客戶和顧問做筆記。我不確定是否應該創建consultants_notes和clients_notes表，還是隻創建一個註釋表？我應該考慮哪些因素？什麼時候DB表應該分成兩個單獨的表？

來源

2012-02-07 blacktie24

你說'內部用戶可以在客戶端和consultants'筆記，並這意味着一個筆記必須有一個InternalUserId和一個ClientUserId或ConsultantUserId？這意味着每個NOTE的兩個字段 – 2012-02-08 00:01:28

註釋將具有internal_user_id和subject_user_id（clientUserId或consultantUserId）。 – blacktie24 2012-02-08 00:07:39

您的評論說：

我真的不知道還多少爲每個用戶類型的音符會有所不同，所以我希望能夠保持它的彈性，如果可能的話

我認爲這兩種方式（一個或兩個表）將足夠靈活。但是，您還應該考慮normalization。如果你後來意識到顧問需要註釋的日期，並且客戶不需要這個字段，那麼你會開始在你的表格上獲得很多空值（空間，好像現在有點花費那麼多：P和缺乏標準化）。

所以看起來一張桌子的解決方案是一個缺點。但是，一個表的解決方案將簡化您的查詢（可讀性），也給你更好的性能（速度），因爲你不會有使每個每個音符表的連接。

的優點和兩個表溶液的缺點實際上是相反的一個表中的那些。那麼，你的主要限制是什麼？如果速度很快，你會選擇一個表格解決方案。在我看來，我會選擇兩個表格解決方案，因爲我無法忍受桌子上有不必要的價值。此外，有一個嚴格的設計，即不允許您將顧客票據價值添加到顧問票據價值的設計，比允許您使用簡單更新來做到這一點要安全得多。儘管您可以爲列值添加限制來解決此問題，但它並不相同。

嗯，這是我的愚見。希望它能幫助，或者至少讓你三思而後行選擇你的設計:)

PS前：要考慮的因素是大膽

來源

2012-02-08 00:28:44

我看到你的標籤php所以除非你使用兩個不同的頁面來讀/寫不同的用戶類型的筆記我會去一個表，因爲你不需要兩個單獨的查詢。除非您希望在表中有數千個註釋，在這種情況下，單獨的表可能更有效。

來源

2012-02-07 22:43:21 Erik

我會用一個表開始：

你已經只有一個表中的任何類型的用戶。
製作三個相同的工件沒有意義（並且使用三個表的代碼的三倍）。 *更多的與各種音符的具體列的表：

但是，如果各種音符將從你可以考慮這是對你更好的人差別很大。 *一個通用表，有些額外的列並不總是被使用。

考慮：

多少音符將被存儲在表中。
什麼數據將被存儲爲每種類型的筆記。

檢查如何構建索引以訪問特定類型的筆記並決定哪些對您更好。

來源

2012-02-07 22:43:31

事情是，我不確定每種用戶類型的筆記會有多少不同，所以我希望能夠保持它的靈活性，如果可能的話。這是一個通用表的問題嗎？ – blacktie24 2012-02-07 22:50:24

我不這麼認爲。您以後可以隨時拆分註釋表 - 只需創建新表格，將註釋移動到新表格併發布使用新數據結構的新版本產品。但現在 - 使用[KISS]（http://en.wikipedia.org/wiki/KISS_principle）和[YAGNI（http://en.wikipedia.org/wiki/You_ain't_gonna_need_it）。 – 2012-02-08 08:47:59

對於三種類型的用戶，你有一張表，那麼爲什麼他們的筆記有三張表？

三張筆記表的問題在於，當您搜索特定用戶的筆記時，您將不得不選擇查看這些表中的一個。您最終將使用if-else語句在您的PHP代碼中對此邏輯進行硬編碼 - 或者 - 您將在查詢中與三個表連接。

如果您決定擁有四種類型的用戶，該怎麼辦？

來源

2012-02-07 22:47:31

什麼時候DB表應該分成兩個單獨的表？

回答

相關問題