多个公司的数据库模式

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。我们公司每个公司都选择一个数据库，每次我们想要进行模式更改时，我们都会为此付费。由于我们的部署是自动化的，它们应该都是相同的，但每次都会有细微的差异。而且，这些数据库真的是独立的，所以很难保持我们的备份同步。

这与所有这些数据库一直很痛苦。唯一的好处是我们可以将它们分散到多台服务器上以提高性能。所以我要投我一票的大数据库设计。