改進我的數據庫設計以實現未來的可伸縮性

Question

嗯，我正在開發一個可能涉及數千用戶的項目&我對數據庫沒有太多經驗，特別是涉及到實體之間的關係時。

讓我解釋一下我的場景。首先有一個用戶可以使用他的憑證登錄我們的系統。我們的系統中有一個模塊，可以讓他創建項目。所以這會帶來用戶表& Projects表之間的關係。

現在還有另外一個模塊，即團隊創建模塊，它完成它所說的。在可用會員名單中，他可以選擇他喜歡的人並將其添加到團隊中。所以有會員表&團隊。此外，成員可以是許多團隊的一部分，團隊可以有許多成員，「用戶」也可以是成員。

我有一個自己設計的數據庫，但我不知道它是好還是壞。此外，如果有人能夠指點我的好教程，我將非常感謝，該教程展示瞭如何插入或更新到涉及關係的表格中。

這裏是我的設計至今：

更新

與他人IRC的討論後，我想出了一個修改後的設計。我合併了「用戶」&「成員」表，因爲用戶也是成員。

我的問題仍然是相同的，我是在正確的軌道？

Answer 1

很長時間以來您在考慮長期使用，但您的解決方案無法長期發揮作用。

這不是第一次嘗試過這種事情。依靠那些以前搞砸的智慧。閱讀數據建模模式書籍。

抽象和規範化。這就是你如何找到一個好的長期解決方案。

至少在派對模特上進行了閱讀。一個團體和個人實際上是相同的（抽象的）事物。

把不同的東西放在不同的表中。地址和成員不屬於同一個表格。

Answer 2

「我在正確的軌道上」不是一個有用的問題 - 我們無法說清楚，因爲它取決於你的前進方向。

幾件事情：

• 這是一個好主意來命名的關係後的關係列。例如，在第一個圖中，項目的「所有者」不應該被稱爲users_user_id--這沒有意義。稱之爲「owner_id」或者有意義地描述項目和成員表之間關係的東西。
• 在第二個圖中，您似乎在成員表中的成員和項目之間具有「多對多」關係 - 但沒有將多個項目的id存儲在成員表中的有效方法。您需要將它列入連接表 - projects_members，例如，就像您對teams_members所做的一樣。
• 「teams_members」表具有一個名爲tm_id的主鍵。純粹主義者會告訴你這是錯誤的 - 該表的唯一標識符應該是member_id和team_id的組合。您不需要另一個唯一標識符 - 實際上它是有害的，因爲您必須保證member_id和team_id組合的唯一性。

正如尼爾所說，你可能想開始閱讀這個。我可以推薦Coronel等人的「數據庫系統：設計，實施和管理」。