Самый эффективный способ вычислить хэш или контрольную сумму для строки со многими столбцами?

Question

У меня есть сценарий, в котором мне нужно проверить, нужно ли обновлять строки в целевой базе данных из исходной базы данных.Исходные данные на самом деле являются представлениями, а данные из этого представления помещаются в таблицу назначения.Поскольку исходное представление собирает / сворачивает / сводит данные из нескольких базовых таблиц, у нас нет действительно хорошего способа изменить схему для поддержки отслеживания изменений, поэтому я подумал о том, чтобы вычислить хэш данных каждой строки и включить их какчасть зрения.Затем мы можем сравнить значение хеша в таблице назначения, чтобы увидеть, есть ли разница, и обновить соответственно.

Мне известны функции:

CHECKSUM
BINARY_CHECKSUM
HASHYBYTES

.Похоже, что CHECKSUM () или BINARY_CHECKSUM () - лучший вариант, но я не уверен, насколько хорошо он будет работать при просмотре с 50 столбцами и миллионами строк.Мне также известно, что сгенерированные контрольные суммы / хэши могут не отличаться даже после редактирования, но в этом случае это допустимо.

Так что вопрос: является ли подход хеш / контрольной суммы хорошим способом сделать это иесли да, то какую функцию лучше использовать?Или есть другой, более эффективный способ решения этой проблемы?

(О, сейчас мы работаем на SQL Server 2005, но скоро перейдем на 2008R2, если это поможет.)

Answer 1

Я не знаю, доверял бы CHECKSUM на самом деле.Я видел много случаев, когда люди документировали, что два разных ряда вызывали столкновение.Вы просто хотите знать, что строка изменилась (или еще не существует в месте назначения)?Отказались ли вы от возможности использования ROWVERSION?Возможно, вы обновляете данные в обоих местах?

Поскольку вы скоро переходите на SQL Server 2008 R2, вы уже подумали о других существующих методах, таких как Отслеживание изменений или Изменить захват данных ?( Сравнение здесь .) Есть и другие способы решения этой проблемы, которые не включают в себя заботу о том, какие строки изменились, но это зависит от вашей конечной цели.В старой системе, с которой я работал, мы массово выталкивали первичные изменения данных в отдельную схему, а затем воспроизводили switcheroo при получении данных.Конечно, все данные были обновлены в источнике, и было нормально, что пункт назначения был на несколько минут позже.Но это помогло избежать сложностей с определением различий между источником и пунктом назначения.