我正在使用c＃和实体框架代码第一种方法开发库存应用程序。
设计要求之一是用户应该能够创建多个公司，每个公司都应该拥有一整套库存主表。
例如，每家公司都应该有自己的股票期刊和项目清单。将来还有一种方法可以将这些公司组合成一个“团体”公司，基本上是合并数据。
使用一个基于文件的RDBMS，比如sqlite，非常简单，我只需要为每个公司创建一个单独的sqlite数据库，然后创建一个主数据库将它们连接在一起。但是，我应该如何在单个数据库文件中执行此操作！不是多个文件数据库。 我不想在每张桌子上都有一个“公司”专栏！
我对DB的知识有限的想法是使用不同的模式分开。每个公司的一个模式，在每个模式中具有相同的表集，并使用单独的模式来保存公共表和表以将其他模式绑定在一起。这是一个好方法吗？因为我很难找到一种方法来首先使用ef和代码“动态”创建模式。
编辑＃1
为了了解公司数量，一家企业拥有大约4-5家公司，每个财政年度，旧公司都被关闭，并创建了一批新公司。在同一个文件中维护多年的数据本质上是件好事，但只要我可以提供一个单独的模块来加载数据几年，从几个db文件中进行年度分析，就不是必需的。
就个别公司数据的规模而言，它可以达到每家公司的GB标记。
模式至少在表级别上经常更改，因为它可以完全由用户自定义。
我想推动我的问题的一个方面是这个设计的实现。如果它是一个具有独立桌面界面和实现的应用程序，并且我在像SQL Server这样的RDBMS服务器上，那么数据库的数量并不重要。但是，对于托管在第三方上并使用其数据库服务器的基于Web的UI，可用的数据库数量将受到限制。唯一的解决方案是使用像SQLite这样的无服务器数据库。 但就一般建议而言，SQLite不建议使用大型企业级数据库。
答案 0 :(得分：4)
您已经提供了可行的解决方案，甚至是一些设计要求，但在不了解基本要求的情况下很难建议“什么是最好的”：
考虑到这一点，关于您的解决方案的一些一般意见。首先，考虑到设计要求，考虑每个公司使用单独的数据库是有意义的。这将分离您的数据，并允许在数据库级别上轻松定义角色和安全性。考虑到你明确提到你可以使用这种方法“简化”，你可以为每个公司创建一个数据库（文件）。通过Entity Framework实现数据访问层，您还可以轻松更改数据库之间的连接字符串，甚至可以使用此方法合并A =＆gt; B中的数据。我认为没有特别的理由，除了维护和更新不同实例的可能风险之外，为什么这不应该是一个需要考虑的解决方案。
另一方面，根据定义，使用one-large-database-for-all方法也不错。维护领域变得更加紧凑，易于接近。分离数据的一种方法是使用不同的数据库模式，如您自己所建议的那样。但是，数据库模式主要用于在基于角色的级别上分离可访问性。例如，后台员工，例如用户角色应该只与“财务”模式进行通信，而dbo可以与几乎任何东西进行通信。您可以在公司基础上扩展这种方法，将公司视为“用户”，但如果您必须创建越来越多的公司，请考虑您将获得的数量的表。这会使您的数据库变得庞大。因此，在我看来，这不是最好的方法。
最后，我对你的声明很感兴趣“我不想在每张桌子上都有'公司'专栏”。在我看来，你也应该考虑这一点。拥有一个discriminator属性，就像几个表上的companyId列一样，很容易使用Entity Framework（或任何ORM）进行抽象。这就是外键的概念所在。此外，它还可以为您提供索引此列的优势。您在此方法中唯一的考虑因素是确保在所有相关表格中提供此“公司鉴别器”。
如果您使用每个单独数据类的合同继承，则使用EF Code First强制执行后者非常简单：
interface IMyTableName {
int companyId;
}
答案 1 :(得分：2)
我同意Moriarty的大部分内容。我们公司选择了每个公司一个数据库的方法，每次我们想要进行模式更改时，我们都会为它付费。由于我们的部署是自动化的，因此它们应该都是相同的，但每次都有很小的差异。而且，这些数据库实际上是独立的，因此很难保持我们的备份同步。
使用所有这些数据库一直很痛苦。唯一的好处是我们可以将它们分散到多个服务器上以提高性能。所以我要投票给一个大数据库设计。