多家公司的数据库架构

Question

我正在使用 c# 和实体框架代码优先方法开发库存应用程序。

其中一个设计要求是用户应该能够创建多个公司，每个公司应该有一套完整的库存主表。

例如，每个公司都应该有自己的股票日记帐和项目清单。将来还有一种方法可以将这些公司合并成一个“集团”公司，本质上是合并数据。

使用像 sqlite 这样的基于文件的 RDBMS，它非常简单，我只需要为每个公司创建一个单独的 sqlite 数据库，然后创建一个主数据库将它们连接在一起。但是我应该如何在单个数据库文件中进行操作！不是多个文件数据库。 我不想在每张桌子上都有一个“公司”列！

我对数据库的有限知识的想法是使用不同的模式进行分离。每个公司的一个模式在每个模式中具有相同的表集，并使用一个单独的模式来保存公共表和表以将其他模式联系在一起。这是一个好方法吗？因为我很难找到一种方法来“动态”首先使用 ef 和代码创建模式。

编辑 #1

要了解公司的数量，一个企业大约有 4-5 家公司，每个财政年度关闭旧公司并创建一组新公司。在同一个文件中维护多年的数据本质上是好的，但只要我可以提供一个单独的模块来加载几年的数据，从几个 db 文件中以方便逐年分析，这不是必需的。

就单个公司数据的大小而言，它可以达到每个公司的 GB 标记。

至少在表级别上，架构更改非常频繁，因为它可以完全由用户自定义。

我想引发我的问题的一个方面是这种设计的实施。如果它是一个具有独立桌面界面和实现的应用程序，并且我在像 SQL Server 这样的 RDBMS 服务器上有我的数据库，那么数据库的数量并不重要。但是，对于托管在第三方上并使用其数据库服务器的基于 Web 的 UI，可用的数据库数量将受到限制。唯一的解决方案是使用像 SQLite 这样的无服务器数据库。 但就一般建议而言，不建议将 SQLite 用于大型企业级数据库。

Answer 1

您已经提供了可行的解决方案，甚至提供了一些设计要求，但是如果不了解基本要求，就很难提出“什么是最好的”建议：

• 现在有多少家公司 - 以及未来可以合理预期的公司
• 每个实例有多少个表
• 每个公司每个“大型”表有多少记录
• 根据数据架构，事物频繁变化的可能性有多大

考虑到这一点，对您的解决方案提出一些一般性意见。首先，考虑到设计要求，考虑为每个公司使用单独的数据库是有意义的。这将分离您的数据并允许在数据库级别上轻松定义例如角色和安全性。考虑到您明确提到您可以使用这种方法“让它变得简单”，您可以为每个公司创建一个数据库（文件）。通过实体框架的数据访问层，您还可以轻松更改数据库之间的连接字符串，甚至使用它合并来自 A=>B 的数据。除了维护和更新不同实例的可能风险外，我认为没有什么特别的原因，为什么这不应该是一个需要考虑的解决方案。

另一方面，使用一个大数据库的方法，从定义上来说也不错。维护领域变得更加紧凑和容易接近。正如您自己建议的那样，分离数据的一种方法是使用不同的数据库模式。但是，数据库模式主要用于在基于角色的级别上分离可访问性。例如，后台员工，例如用户角色应该只与“财务”模式通信，而 dbo 几乎可以与任何东西通信。您可以在公司基础上扩展此方法，将公司视为“用户”，但请考虑如果您必须创建越来越多的公司，您将获得的表格数量。这将使您的数据库变得庞大。因此，在我看来，这不是最好的方法。

最后，我对您的陈述“我不想在每张桌子上都有一个 '公司' 列”很感兴趣。在我看来，你也应该考虑这一点。拥有一个鉴别器属性，比如几个表上的 companyId 列，很容易使用实体框架（或任何 ORM）来抽象。这就是外键的概念。此外，它还会为您提供索引此列以提高性能的优势。在这种方法中，您唯一需要考虑的是确保在所有相关表格上提供此“公司鉴别器”。

如果您为每个单独的数据类继承一个契约，那么使用 EF Code First 执行后者将非常简单：

interface IMyTableName {
    int companyId;
}

不过，这只是我的快速想法。

Answer 2

我在很大程度上同意莫里亚蒂的观点。我们公司选择了每个公司一个数据库的方法，每次我们想要进行架构更改时都需要为此付费。由于我们的部署是自动化的，它们应该都是相同的，但每次都有细微的差别。此外，这些数据库确实是独立的，因此我们的备份也很难保持同步。

使用所有这些数据库非常痛苦。唯一的好处是我们可以将它们分布在多个服务器上以提高性能。因此，我将投票支持一个大型数据库设计。