提高大数据上下文的性能

Question

我正在使用一个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？

Answer 1

将您的DataContext划分为较小的单独DbSet集合是否明智，取决于表是否相关以及所使用的数据库管理系统的类型。

如果您使用像Microsoft DBMS这样的专业DBMS，那么对于此DBMS 145表来说，处理起来并不多。如果将所有表保存在一个数据库中，不会有任何问题。

如果您的一个表变得依赖于另一个数据库中的一个表，将来将表拆分为单独的数据库可能会导致问题。

另一方面，对于像SQLight这样的简单DBMS，很多表和很多同时查询可能对它来说太多了。

如果表之间确实没有任何关系，请考虑将它们分成单独的数据库。例如，如果您有一个包含“客户”，“产品”，“订单”，“价格”，“发票”等的数据库，以及另一个具有“学校”，“学生”，“课程”，“教室”，“老师”等的数据库。那么，任何“学校”表都不可能与订单表。

[如果您稍后决定添加带有地址的表，则具有主键PostCode + HouseNumber。在发票数据库中，客户有地址。在您的学校数据库中，学校，老师和学生都有地址。

如果您有单独的数据库，则必须两次实施（并填充！）地址。如果既是客户又是学校的老师的约翰·多伊（John Doe）搬到另一个城市，则您必须两次更改地址。

另一方面，单独的数据库将使您有机会首先在发票数据库中，然后在Schools数据库中，将地址添加为单独的表。您甚至可以决定让发票具有与学校不同的地址系统。或者，也许您希望发票系统的地址表与学校系统的地址表不同。

所以是否应该拆分：

dbContext位于本地内存中的原因不符合条件。 DbContext不保存数据库的数据，它仅保存查询数据的可能性。

但是，某些类型的DbContext（例如，实体框架）也会记住已经获取的数据。通常，人们只能将dbContext保留很短的时间，以防止您在查询数据时错过其他人所做的更改。因此，即使在这种情况下，这也不会影响您选择一个或两个数据库。