為具有多種使用者類型的場景設計多租戶數據庫
我正在開發一個用於招聘的 SaaS 應用程序，它具有多種使用者類型，例如
Client、等 。使用者類型也有可能增加。Recruiter``Panellist``Owner有
Owner一個Organization，這就是我的租戶。在這裡，我將每個所有者的組織都視為租戶。我正在使用 Django 開發此應用程序，並將利用 PostgreSQL 中提供的模式功能，因此每個租戶都有一個模式。我打算做的是有一個全域
User表，它將保存在公共模式中，並儲存通用使用者資訊，如名字、姓氏、電子郵件、密碼等。該User表將用於登錄網站。並且每個使用者類型都會有額外的表，每個使用者類型都有自己獨特的列集。這些附加表將特定於租戶/組織。現在，一旦使用者登錄到站點，他就可以切換到他想要的租戶/組織，類似於 Slack 中工作區的功能。在租戶/組織內，使用者可以承擔上述分配給使用者的使用者類型的角色
Owner。所以使用者可以是Recruiter一個租戶，他也可以是Panellist另一個租戶。將有一個
UserOrganization聯結表，它將跟踪 aUser可以屬於 multiple的事實Organization。這是我在想的架構圖：
注意：我沒有為第二個租戶中的表建立模式連接，因為它開始變得混亂，但出於所有意圖和目的，假設它們存在於那裡。
我的問題是：
- 在多租戶場景中處理多個使用者時，最佳實踐究竟是什麼？
- 我的設計有哪些不足之處？
如果租戶很少，使用多個模式來實現多租戶場景是一個可行的解決方案。如果你有太多的租戶，你最終會得到太多的桌子，這會讓你的生活很痛苦。
如果您有很多租戶，您可以為所有租戶使用一個表並使用類似的列
tenant_id來標識它們。如果您不想信任應用程序邏輯以將查詢結果限制為適當的租戶，您可以使用行級安全性並讓數據庫為您完成。“單表”方法的另一個有用工具是分區。您可以使用列表分區將大表拆分為基於租戶的分區。這樣，您可以將多個（較小的）租戶捆綁在一個分區中。分區將更容易刪除單個租戶的所有數據（這是它的主要優點），並且可以為您節省
tenant_id. 大多數查詢不會通過分區變得更快。
我現在處於類似的情況，試圖做出決定，我對使用一個數據庫和共享模式進行多模式感到有點麻痺。無論如何，關於您的文章，為什麼每個角色都有一個單獨的表格？正如您所說，角色可以增加，這意味著您每次都必須創建額外的表？我會使用一個表和一個角色列來區分使用者角色或進行多對多設置，因為一個使用者可以擁有多個角色並且一個角色可以屬於多個使用者。讓我知道你是否實現了這個，如果是的話，多模式的體驗如何