2010-07-15 83 views
2

什么会使用LINQ时,必须考虑更新的最佳实践:LINQ更新程序 - 最佳实践

  • 为了有一个实例DB /门面 对象,并提交所有更改到 纪录一个去了?
  • 要有一个静态的数据库/外观对象, 并提交逐个单元格更改?

现在我在一个项目中,用于记录每个单元都有其自己的静态更新方法

public static void CellName(int id, int data) 
{ 
    using (var scope = new someDataContext()) 
    { 
      var TableName = scope. CellName.Single(v => v.ID == id); 
      TableName.CellName = data; 
      scope.SubmitChanges(); 
    } 
} 

这些就被设置为业务对象的属性,按照通常TableName.CellName = [something]方案。

但我也做过项目,我们已经使用了实例化的db/facade类。首先设置属性等新值,然后调用database.SubmitChanges()方法,然后对整个记录(或记录)进行更新。

从设计角度来看,我更喜欢第一个选项 - 当设置属性时,更改是即时的,并且与其他任何对象一样。但从技术角度来看,我怀疑通过批量更新可以获得性能。

那么我应该选择哪种方法 - 还是应该考虑其他选择?

回答

1

更新invidual单元效率极低。更新数据库的主要开销是实例化连接,发送&接收答复,并在表中找到要更新的行。如果您更新每个单元格,那么您需要为每个单元格执行这些步骤 - 如果您更新每行,那么它每行一次。

更新细胞单独是写作SQL的像

-- new command 
UPDATE [Table] SET [Column1] = 'Value1' WHERE [Id] = 1 
GO 
-- new command 
UPDATE [Table] SET [Column2] = 'Value2' WHERE [Id] = 1 
GO 
-- new command 
UPDATE [Table] SET [Column3] = 'Value3' WHERE [Id] = 1 
GO 

其中命令被串行处理的等价物,并在每个命令等待直到前面的指令执行之前完成。虽然这可能不会比一次更新整行更慢,但是可能会更慢,并且绝对不会更快。

首选的方法是一次更新所有属性,然后发送一个SQL命令。

UPDATE [Table] 
SET [Column1] = 'Value1', [Column2] = 'Value2', [Column3] = 'Value3' 
WHERE [Id] = 1 

有几个步骤涉及,如果你在物理上和实际上考虑它应该都是有意义的。

首先,LINQ-to-SQL检索整行,以便更新属性。 '每个单元格'或'每行'操作都需要这样做,所以需要相同的时间。

// the "Single" operator retrieves an entire row 
var TableName = scope.CellName.Single(v => v.ID == id); 
var row = scope.MyTable.Single(v => v.Id == id); // more accurate description 

-- sql looks something like this 
SELECT TOP 1 * FROM [MyTable] WHERE [Id] = @id 

这涉及

  • 编译查询
  • 打开连接/取回从池中
  • 发送命令到SQL服务器
  • 从SQL接收答复的连接服务器

C与其他服务器通信可能需要几毫秒到几秒的时间,具体取决于距离,性能,服务器负载等。

然后更新一个属性。

row.Column1 = data; 

这只需要几个周期。这是整个运营时间中不可估量的一小部分。

然后您提交更改。

scope.SubmitChanges(); 

-- sql looks like this 
UPDATE [MyTable] SET /* set of columns to update */ WHERE [Id] = @id 

这又涉及许多步骤

  • 编译查询
  • 发送命令到SQL Server
  • 接收从SQL Server响应

没有什么'瞬间'关于单独更新单元格 - 单元格将在整行更新的同时更新d使用'每行'模式进行更新。只是剩下的细胞将会更新较长的

不仅如此,从您的问题看,您还将拥有数百种样板UpdateProperty方法。我从来没有见过或听说过这样的模式,但说实话这听起来很糟糕 - 你发送的SQL命令比必要的要多很多倍,而且你的数据库延迟乘以表中的列数。