2010-07-15 81 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命令比必要的要多很多倍,而且你的數據庫延遲乘以表中的列數。