數據庫中的自跟蹤實體與時間戳列

在Web應用程序的一個樂觀併發場景中，我正在考慮爲每個表提供與guid相當的時間戳列（sqlserver）。當實體框架中的某個屬性裝飾時間戳列時，實體的Linq將生成SQL更新查詢，如WHERE id = @p0 AND timestamp = @p1。當返回的更新記錄數量爲0時，我們檢測到併發異常。數據庫中的自跟蹤實體與時間戳列

在很多文章中，我正在閱讀有關自追蹤實體，這可能是一種替代或更好的解決方案。但是我沒有看到上述「簡單」時間戳方法的優勢。除了數據庫不可變且不提供時間戳列的情況之外。

哪種解決方案更好，爲什麼？

編輯

Yury Tarabanko正確地指出STE是另一個概念。然而zeeshanhirani的答案表明併發檢查是追蹤變化的一個主要動機。

讓我們重述一下這個問題：爲什麼會有人使用STE概念進行併發檢查，其中'timestamp列'方法看起來更容易。

來源

2010-07-05 Gerard

您在這裏混合了兩個概念。 STE根本不是關於併發性的。

自我跟蹤實體只是知道如何做他們的變化跟蹤這些變化是如何進行的。所以你總是知道實體對象圖的當前狀態是什麼。而且您不需要調用其他更改檢測。

什麼是STE。

編輯：

「併發檢查是跟蹤變化一個主要動機」

AFAIK國營和波蘇斯共享相同的方法來併發檢查它簡單地導致額外的，其中（多個）條件在發送到數據庫的更新語句中。相當於此：

UPDATE [schema].[table] 
    SET [prop1] = value1, ... 
    WHERE [key] = key_value 
      AND [concurrency_prop_1] = concurrency_prop1_old_value 
      AND [concurrency_prop_2] = concurrency_prop2_old_value

因此，跟蹤更改的「主要動機」是跟蹤N層應用程序的更改。

來源

2010-07-05 20:56:31

不夠公平。但是這個問題怎麼樣：爲什麼有人想爲併發檢查做這件事，'timestamp'方法看起來更自然，更容易。 – Gerard 2010-07-12 08:32:50

我認爲沒有人會爲了併發檢查而選擇STE。 STE不關於併發性。正如@zeeshanhinari所指出的那樣：「STE與'併發檢查概念一起工作。他們通過線路發送併發令牌的原始值。如果他們沒有，你將無法在另一層多層應用程序中檢查這些值。「的想法是創建智能實體對象，跟蹤他們自己的變化和相關實體的變化。「 – 2010-07-12 09:00:43

自追蹤實體實際上與您所描述的概念一起工作。當上下文不在時，STE基本上跟蹤對象的變化。但是，當它使用WCF服務將更改發送回服務器時，它會發送屬性的當前值，實體的新狀態以及主鍵列的原始值，任何列的獨立關聯值和原始值在實體數據模型中標記爲併發=固定。

來源

2010-07-07 05:34:40 zeeshanhirani

順便說一句，w.r.t.」主鍵列的原始值「：永遠不會更改主鍵 - 更改設計（例如刪除和添加）！ – Gerard 2010-07-07 08:22:49

數據庫中的自跟蹤實體與時間戳列

回答

相關問題