我正在使用一个DataContext，它具有145个带有许多引用的表。我已经阅读了几篇文章和帖子，关于在这种情况下将DataContext拆分为更好的方法，最佳实践似乎是使用一个大型DataContext。由于DataContext已加载到内存中，因此性能不应受到太大影响。
尽管如此，我的测试表明，在减少表的数量之后，仅实例化DataContext每次大约需要90毫秒。
例如，此代码将花费近10秒钟：
For i As Integer = 0 To 100
Using db As New MyDataContext()
End Using
Next
是否有一种方法可以提高具有许多表的DataContext的性能，还是应该尝试使用多个DataContext？
答案 0 :(得分：0)
将您的DataContext分成较小的单独DbSet集合是否明智，取决于表是否相关以及所使用的数据库管理系统的类型。
如果使用专业的DBMS（例如Microsoft DBMS），那么对于此DBMS 145表来说，处理起来并不多。如果将所有表都保存在一个数据库中，就不会有任何问题。
如果您的一个表变得依赖于另一个数据库中的一个表，将来可能会将表拆分为单独的数据库可能会导致问题。
另一方面，对于像SQLight这样的简单DBMS来说，很多表和很多同时查询可能对它来说太多了。
如果您的表之间确实没有任何关系，请考虑将它们分成单独的数据库。例如，如果您有一个包含“客户”，“产品”，“订单”，“价格”，“发票”等的数据库，以及另一个具有“学校”，“学生”，“课程”，“教室”，“老师”等的数据库。那么，任何“学校”表都不可能与订单表。
事件，如果您稍后决定添加带有地址的表，该表具有主键PostCode + HouseNumber。在发票数据库中，客户有地址。在您的学校数据库中，学校，老师，学生都有地址。
如果您有单独的数据库，则必须两次实施（并填充！）地址。如果既是客户又是学校的老师的约翰·多伊（John Doe）搬到另一个城市，您将不得不两次更改地址。
另一方面，一个单独的数据库将使您有机会首先将地址作为单独的表添加到发票数据库中，然后再添加到Schools数据库中。您甚至可以决定让发票具有与学校不同的地址系统。或者，也许您希望发票系统的地址表与学校系统的地址表不同。
所以您是否应该拆分：
dbContext位于本地内存中的原因不符合条件。 DbContext不保存数据库的数据，只保存查询数据的潜力。
某些类型的DbContext（例如，实体框架）也可以记住已经获取的数据。通常，人们仅将dbContext保留很短的时间，以防止您在查询数据时错过其他人所做的更改。因此，即使在这种情况下，这也不会影响您选择拥有一个或两个数据库。