這個數據庫設計邏輯會起作用嗎？應該使用什麼？
幾週前，我的一個客戶問我開發一個類似於 highrisehq.com 提供的自定義 CRM 應用程序會有多複雜
他本質上想要做的是為特定行業內的外部銷售代表提供訪問權限，以使用此 CRM 應用程序來管理他們的所有聯繫人、客戶和通信/任務。
highrisehq 和這個系統之間的主要區別在於，他希望讓這些銷售代表中的每一個都能夠相互“共享”數據。現在我的意思是：
假設系統中有兩個獨立的 CRM 帳戶使用者，每個帳戶都有數千個聯繫人和數百個關係（將公司連結到聯繫人，將聯繫人/公司連結到項目，將聯繫人連結到消息/任務/通知）。
現在……他想做的是讓這兩位銷售代表都擁有自己的獨立帳戶，以便能夠彼此共享資訊。
我的想法是，這裡應該發生的第一件事是一個使用者通過系統向另一個使用者發起“共享”請求。在接受此共享請求後，兩個帳戶現在都具有與其他帳戶共享資訊的“能力”。
我的想法是，一旦這些帳戶被連結，該使用者現在可以顯示為“共享使用者”，並顯示在您通常為單個使用者設置查看/編輯權限的所有區域。
在我看來，事情變得複雜的地方是如何顯示“活動流”，例如，因為基本上現在系統不僅顯示我的帳戶的所有活動，而且還顯示使用者已被授予訪問權限的外部帳戶的所有活動。
此外……如果使用者有 100 個帳戶，他正在與之共享資訊，我能做些什麼來確保系統不會慢到爬行嗎？
應該使用什麼最合乎邏輯、最好和最便宜的數據庫邏輯來創建這些關係，以便對單個帳戶的查詢以與必須從多個帳戶訪問數據時相同的速度返回數據？
你們認為應該考慮或“必須具備”功能的任何其他關鍵方面？
我真的必須鼓勵您查看現有 CRM 系統處理數據庫模式的方式，並考慮（1）您是否不會進一步定制這些系統之一，以及（2）您不會比您更努力可以咀嚼。
我見過的大多數 CRM 系統都內置了廣泛的定制功能。通常，這包括擴展和/或修改內置實體定義的能力以及添加新實體類型和關係的能力。這些 CRM 系統中的許多系統還能夠設置一些非常時髦的安全設置，有些可能能夠執行類似於您建議的操作。
我還鼓勵您嘗試從該客戶端中撬出一個業務場景。是什麼讓他確信銷售代表會分享資訊？如果他們在一個團隊中一起工作，那麼現有的 CRM 系統已經涵蓋了這一點。如果不是，那麼我對資訊共享的前提有點懷疑。了解銷售代表將在他們的行為方面跟隨金錢。如果他們為分享資訊而獲得報酬，那麼它就會發生；否則，您將不得不用棍子擊敗他們才能分享任何東西。
這根本不應該是一個問題。只要進行了適當的索引，並且您擁有完善的數據庫設計和適當大小的硬體，您就不應該有任何問題。