Отключенные обновления LINQ: версия строки и дата / время с триггером?

Question

Мы используем LINQ to SQL и WCF для нового среднего уровня, и мы используем объекты передачи данных для передачи по проводам, а не фактические классы LINQ.Я собираюсь использовать один или другой из описанных здесь методов - Linq Table Attach (), основанный на отметке времени или версии строки - для обеспечения корректной работы обновлений и правильной обработки параллелизма.

Чтобы сэкономить вам немного времени на чтение, по сути, вы можете либо использовать столбец метки времени / строки в своей таблице, либо иметь столбец даты-времени со значением по умолчанию и триггером обновления - в любом случае он получает столбец, который получаетвновь создаваемое значение каждый раз, когда происходит вставка или обновление, и этот столбец используется LINQ для проверки на параллелизм.

Мой вопрос - какой из них лучше?У нас уже есть столбцы даты и времени для «UpdateWhen» во многих наших таблицах (но не во всех - не спрашивайте), но мы добавим значения по умолчанию и триггеры, или мы могли бы просто добавить версию строки (нам пришлось бы использоватьсинтаксис временной метки на данный момент, так как мы все еще поддерживаем SQL2005 некоторое время) для каждой таблицы - в любом случае мы модифицируем БД, чтобы она работала, поэтому я хотел бы знать, есть ли разница в производительности или какая-либоДругое важное отличие, которое следует отметить между этими двумя альтернативами.Я пытался искать в Интернете и здесь на SO, но пока не повезло.Спасибо.

Answer 1

Недавно мне пришлось принять аналогичное решение.

Сначала я попробовал решение для преобразования строк.
Обнаруженные мной недостатки:

• Неудобное использование в LINQ-to-SQLЯ сопоставил поле с байтом [].Код не выглядит чистым, когда вы сравниваете байтовые массивы
• Теоретически rowversion может перевернуться и начать снова с 0, поэтому строка с более высоким rowversion не обязательно будет более старой строкой
• Rowversionобновляется при любом обновлении строки, что в моем случае было нежелательно, мне нужно было исключить некоторые столбцы, чтобы не влиять на версию строки.Наличие триггера позволяет реализовать любой уровень гибкости.

В результате я использовал столбец datetime2 с ограничением по умолчанию и триггер обновления, чтобы установить значение sysutcdatetime ()
.Этот тип имеет точность 100 наносекунд (точность 7 цифр - 23: 59: 59.9999999)
.Хотя это возможно, я еще никогда не видел генерацию одного и того же значения дважды.Но в моем случае не повредит, если будут дубликаты.Если бы это было важно для меня, я бы добавил уникальное ограничение и посмотрел бы, может ли это когда-нибудь произойти.

Я использовал sysutcdatetime (), поскольку это значение не будет зависеть от перехода на летнее время.

Answer 2

Я бы склонялся к использованию столбца timestamp для проверок параллелизма. Один - триггеры будут иметь некоторое влияние на производительность, а второй - со столбцом даты и времени, вы будете ограничивать себя точностью столбца DateTime в SQL и C #.

MSDN:

значения даты и времени округляются до приращений .000, .003 или .007 секунд ...

Возможно, вы захотите взглянуть на SO: есть ли разница между DateTime в c # и DateTime на SQL-сервере? и MSDN: datetime (Transact-SQL) для получения дополнительной информации.