多個公司的數據庫模式

Question

我正在使用c＃和實體框架代碼第一種方法處理庫存應用程序。

其中一個設計要求是用戶應該能夠創建多個公司，並且每個公司應該擁有一整套庫存主表。

例如，每個公司都應該有自己的庫存日記和項目清單。還有一種方法可以將這些公司組合起來，形成一個「集團」公司，從本質上合併數據。

使用基於文件的RDBMS像sqlite的之一，它的很簡單，我只需要爲每家公司單獨SQLite數據庫，然後主數據庫將其結合在一起。但是，我應該如何去做一個單一的數據庫文件！不是多個文件數據庫。 我不想在每張桌子上都有「公司」欄！

我給了我有限的DB知識的想法是使用不同的模式分離。每個公司都有一個架構，每個公司在每個架構中都有相同的一組表，並且有一個單獨的架構來管理常見的表和表，以便將其他架構捆綁在一起。這是一個好方法嗎？因爲我很難找到一種方法來'動態'使用ef和代碼先創建模式。

編輯＃1

要獲得公司數量的概念，一個企業擁有約4-5的公司，並在每個財政年度的老企業封閉和一套新的企業的創建。在同一個文件中保存多年的數據本質上是好的，但只要我可以提供一個單獨的模塊來加載數年的數據，就可以從幾個數據庫文件中進行逐年分析，這並不是必需的。

至於個別公司數據的大小，它可以擊中每家公司GB大關。

架構的變化很頻繁，至少在桌子上水平，這將是完全由用戶自定義。

我想推動我的問題的一個方面是實施這種設計。如果它是一個具有離散桌面接口和實現的應用程序，並且我擁有像SQL Server一樣的RDBMS服務器，那麼數據庫的數量並不重要。但是，對於託管在第三方並使用其數據庫服務器的基於Web的UI，可用數據庫的數量將受到限制。唯一的解決方案是使用像SQLite這樣的無服務器數據庫。 但是，就一般建議而言，SQLite不建議用於大型企業級數據庫。

Answer 1

你提供可行的解決方案，甚至有些設計要求，但很難勸「什麼是最好的」不知道像底座的要求：

• 有多少企業現在 - 並且可以合理地預期每個實例未來
• 多少桌
• 每個「大」表中有多少條記錄，每家公司
• 多大可能的事情經常改變，dataschema明智

考慮到這一點，關於您的解決方案的一些一般意見。首先，考慮到設計要求，考慮使用單獨的公司數據庫是有意義的。這將分離您的數據，並允許在數據庫級別上定義角色和安全性。考慮到你明確提到你可以使用這種方法「簡單化」，你可以爲每個公司創建一個數據庫（文件）。使用Entity Framework的數據訪問層，您還可以輕鬆更改數據庫之間的連接字符串，甚至可以使用此功能合併來自A => B的數據。我沒有看到特別的原因，除了維護和更新不同實例的風險之外，爲什麼這不應該是一個需要考慮的解決方案。

另一方面，使用one-big-database-for-all方法，其定義也不錯。維護領域變得更加緊湊，易於平易近人。正如你所建議的那樣，分離數據的一種方法是使用不同的數據庫模式。但是，數據庫模式主要用於在基於角色的級別上分離可訪問性。例如，一個後勤員工例如用戶角色只應該與「財務」模式進行溝通，而dbo可以與任何事情交流。您可以在公司基礎上擴展此方法，將公司視爲「用戶」，但考慮如果您必須創建越來越多的公司，您將獲得表的數量。這會讓你的數據庫變大。因此，在我看來，不是最好的方法。

最後，我對你的陳述很感興趣：「我不想在每張桌子上都有'公司'專欄」。在我看來，你應該考慮這一點。擁有一個鑑別屬性，就像幾個表上的companyId列一樣，使用Entity Framework（或者任何ORM）很容易進行抽象。這就是外鍵的概念。此外，它會給你的索引本專欄的優勢表現。這種方法唯一的考慮是確保你在所有相關的表格上提供這個「公司鑑別者」。

後者將是相當簡單的使用EF代碼首先，如果你使用的合同爲每個單獨的數據類繼承強制執行：

interface IMyTableName { 
    int companyId; 
} 

只是我最新的想法，雖然。

Answer 2

我大部分都同意Moriarty。我們公司每個公司都選擇一個數據庫，每次我們想要進行模式更改時，我們都會爲此付費。由於我們的部署是自動化的，它們應該都是相同的，但每次都會有細微的差異。而且，這些數據庫真的是獨立的，所以很難保持我們的備份同步。

這與所有這些數據庫一直很痛苦。唯一的好處是我們可以將它們分散到多臺服務器上以提高性能。所以我要投我一票的大數據庫設計。