cod*_*rik 5 c# database-design entity-framework database-schema
我正在使用 c# 和实体框架代码优先方法开发库存应用程序。
设计要求之一是用户应该能够创建多个公司，每个公司应该有一套完整的库存主表。
例如，每个公司都应该有自己的股票日记帐和项目清单。将来还有一种方法可以将这些公司合并成一个“集团”公司，实质上是合并数据。
使用一种基于文件的 RDBMS（如 sqlite），它非常简单，我只需要为每个公司创建一个单独的 sqlite 数据库，然后创建一个主数据库将它们联系在一起。但是，我应该如何在单个数据库文件中进行操作！不是多个文件数据库。我不想在每张桌子上都有一个“公司”列！
我对数据库的有限了解的想法是使用不同的模式进行分离。每个公司的一个模式在每个模式中具有相同的一组表，一个单独的模式保存公共表和表以将其他模式联系在一起。这是一个好方法吗？因为我很难找到一种首先使用 ef 和代码“动态”创建模式的方法。
编辑 #1
为了了解公司的数量，一个企业大约有 4-5 家公司，每个财政年度关闭旧公司并创建一组新公司。在同一个文件中维护多年的数据本质上是好的，但不需要，只要我可以提供一个单独的模块来加载几年的数据，从几个db文件中方便逐年分析。
就单个公司数据的大小而言，它可以达到每个公司的 GB 标记。
至少在表级别上架构更改非常频繁，因为它可以由用户完全自定义。
我想促使我提出问题的一个方面是这种设计的实现。如果它是一个具有独立桌面界面和实现的应用程序，并且我在像 SQL Server 这样的 RDBMS 服务器上运行，那么数据库的数量就没有那么重要了。但是，对于托管在第三方并使用其数据库服务器的基于 Web 的 UI，可用数据库的数量将受到限制。唯一的解决方案是使用像 SQLite 这样的无服务器数据库。但就一般建议而言，不建议将 SQLite 用于大型企业级数据库。
您已经提供了可行的解决方案，甚至一些设计要求，但在不了解基本要求的情况下，很难提出“什么是最好的”建议，例如：
考虑到这一点，对您的解决方案发表一些一般性意见。首先，考虑到设计要求，考虑为每个公司使用单独的数据库是有意义的。这将分离您的数据并允许在数据库级别很容易地定义例如角色和安全性。考虑到您明确提到您可以使用这种方法“使其变得简单”，您只需为每个公司创建一个数据库（文件）。通过实体框架的数据访问层，您还可以轻松更改数据库之间的连接字符串，甚至可以使用它合并来自 A=>B 的数据。除了维护和更新不同实例可能存在的风险之外，我认为没有特别的原因，为什么这不应该是一个需要考虑的解决方案。
另一方面，使用一个大数据库的方法，从定义上来说也不错。维护领域变得更加紧凑且易于接近。分离数据的一种方法是使用不同的数据库模式，正如您自己建议的那样。但是，数据库模式主要用于在基于角色的级别上分离可访问性。例如，后台员工（例如用户角色）应该只与“财务”模式进行通信，而 dbo 几乎可以与任何内容进行通信。您可以在公司基础上扩展这种方法，将公司视为“用户”，但想想如果您必须创建越来越多的公司，您将获得多少表。这将使您的数据库变得庞大。因此，在我看来，这不是最好的方法。
最后，我对您的陈述“我不想在每个表上都有一个‘公司’列”很感兴趣。在我看来，你也应该考虑这一点。使用实体框架（或任何与此相关的 ORM）具有鉴别器属性，例如多个表上的 companyId 列非常容易抽象。这就是外键的概念。此外，它还可以为您提供索引此列以提高性能的优势。在这种方法中，您唯一的考虑是确保在所有相关表格上提供此“公司鉴别符”。
如果您为每个单独的数据类使用契约来继承，那么使用 EF Code First 强制执行后者将非常简单：
interface IMyTableName {
int companyId;
}
不过，这只是我的快速想法。
| 归档时间： |
|
| 查看次数： |
2385 次 |
| 最近记录： |