我正在製作一個客戶端管理應用程序，其中我存儲了employee，admin和company的數據。將來該數據庫將有數百家公司註冊。我正在考慮採用最佳的數據庫設計方法。爲大數據創建數據庫表
我能想到的方法2：
您能否做到這一點的最好辦法？
請注意，所有3張桌子都以ID爲基礎進行鏈接，並且會有數百家公司，每家公司將擁有多個管理員，每個管理員將擁有數百名員工。根據應用程序的使用情況，不存在「最佳」方式，那麼對安全性和查詢性能來說最好的方法是什麼
使用您提供的部分信息，它看起來像3個標準化表格是你需要什麼，以及諸如查找和其他內容等輔助數據。
但是，當你設計一個數據庫，你需要考慮像，安全性，可視性，客戶端訪問方法更多一點，等
例如，如果你想確保隔離，不要讓用戶有任何對其他數據的可見性，您可以動態創建每個公司的模式，動態地爲每個模式創建用戶和訪問權限。那麼你需要在DAL中支持這些東西，事實上它會很胖。
DA1的另一種方法可能是暴露始終爲一個公司返回子集的視圖。
我建議採用標準化方法的一個重要原因是維護將會更容易。
從SQL的角度來看，我沒有看到任何具有許多表的性能優勢，或者只有3個，索引效率和智能DAL會帶來差異。
。 請解釋您的應用程序將提供的操作，以便我們可以進一步瞭解您的問題。
要存儲的數據似乎是結構化的，所以乍一看關係數據庫可以很好地工作，但堅持我在上面標記的點。
你還沒有說過這個數據如何鏈接，或者它們之間是否有任何鏈接。但是，猜測你需要3個表格。
與每一個在那裏所要求的性能，無需額外的信息，我不能提供任何更多的指導。
查詢的性能很大程度上取決於表的大小，但它更多依賴於該表上的索引。因此您需要根據您的要求放置聚簇索引和非聚簇索引，並且我可以保證高達10 GB的數據不會面臨任何問題
我讀了聚簇索引，它說它將存儲值靠近另一個表，所以我有所有三個表互連，所以我會去所有三個表的聚集索引。如果我錯了，請糾正我。謝謝 – Uahmed
這是一個經典問題，分享了我的大部分Web業務服務：討論涉及的因素，谷歌「多租戶架構」。
你幾乎可以肯定地想把所有的公司放到一個通用的表中：每個數據表都應該引用公司密鑰，並且所有查詢都應該加入這個密鑰，而不是其他標準。這樣可以獲得最佳的整體性能，並且可以節省數百次重複視圖，存儲過程等潛在的維護噩夢，或者如果希望添加字段或表格，必須將相同的結構更改應用於數百個表。
爲了確保您不會無意中混淆來自不同客戶的數據，通過一組經驗證的存儲過程（所有這些都將公司ID作爲參數）執行所有數據訪問可能很有用。
數以百計的並行數據庫不會很好地擴展：數據庫服務器將不斷推動表和索引內存不足以適應下一個查詢，導致磁盤抖動和性能下降。這條路只有痛苦。
感謝您的回覆。所以情景是，我將擁有數百家公司，每家公司都有很多管理員，每個管理員都有數百名員工。現在你說什麼，我應該存儲在3個表中的所有值，或者我爲每個公司製作3張表的複製品。如果我製作副本比數據將以更多組織方式。你所說的 – Uahmed
@ user1224233恰恰相反，我並不是說在許多類似的表中有數據會使事情更加有組織，它只會在安全角度上有一些好處，但是需要更多的努力來創建並保持。在這個特定的情況下，很少規範化的表格會更有組織。 –
我完全同意你的理由，我認爲單獨的表只是安全的事情。在我的情況下，每個公司都與另一家公司沒有任何關係，並且採用第二種方法將所有數據都放在3個表中，我只考慮安全問題和查詢響應時間，因爲這可能只有一家公司擁有如此多的數據，並且僅僅因爲該查詢延遲發生 – Uahmed