Каковы различия между CHECKSUM() и BINARY_CHECKSUM() и когда/какими являются соответствующие сценарии использования?

Снова MSDN на самом деле не объясняет точную разницу или информацию о том, когда выбрать один над другим.

CHECKSUM

Возвращает значение контрольной суммы, вычисленное по строке таблицы, или по списку выражений. CHECKSUM предназначен для использования при построении хэш-индексов.

BINARY_CHECKSUM

Возвращает значение двоичной контрольной суммы, вычисленное по строке таблицы или по списку выражений. BINARY_CHECKSUM может использоваться для обнаружения изменений в строке таблицы.

Он намекает, что двоичная контрольная сумма должна использоваться для обнаружения изменений строк, но не почему.

Ответы

Ответ 1

Ознакомьтесь со следующим сообщением в блоге, в котором подчеркиваются различия.

http://decipherinfosys.wordpress.com/2007/05/18/checksum-functions-in-sql-server-2005/

Добавление информации по этой ссылке:

Основной целью функций CHECKSUM является построение хеш-индекса на основе выражения или списка столбцов. Если вы используете его для вычисления и хранения столбца на уровне таблицы, чтобы обозначить контрольную сумму по столбцам, которые делают запись уникальной в таблице, тогда это может быть полезно при определении того, изменилась ли строка или нет. Затем этот механизм можно использовать вместо объединения со всеми столбцами, которые делают запись уникальной, чтобы увидеть, была ли эта запись обновлена или нет. В SQL Server Books Online есть много примеров этой функциональности.

Несколько вещей, которые следует учитывать при использовании этих функций:

Вы должны убедиться, что столбец (столбцы) или порядок выражения совпадают между двумя контрольными суммами, которые сравниваются, иначе значение будет отличаться и приведет к возникновению проблем.

Мы бы не рекомендовали использовать контрольную сумму (*), поскольку значение, которое будет генерироваться таким образом, будет основываться на порядковом столбце определения таблицы во время выполнения, которое может легко измениться с течением времени. Итак, явно укажите список столбцов.

Будьте внимательны при включении столбцов данных типа datetime, поскольку степень детализации составляет 1/300 секунды и даже небольшая вариация приведет к другому значению контрольной суммы. Итак, если вам нужно использовать столбец данных типа datetime, то убедитесь, что вы получили точную дату + час/мин. т.е. уровень детализации, который вы хотите.

Доступны три функции контрольной суммы:

CHECKSUM: Это было описано выше.

CHECKSUM_AGG: возвращает контрольную сумму значений в группе, а значения Null в этом случае игнорируются. Это также работает с новым предложением OVER аналитических функций в SQL Server 2005.

BINARY_CHECKSUM: Как указано в названии, это возвращает значение двоичной контрольной суммы, вычисленное по строке или списку выражений. Разница между CHECKSUM и BINARY_CHECKSUM заключается в значении, генерируемом для строковых типов данных. Примером такой разности являются значения, генерируемые для "DECIPHER" и "decipher", будут отличаться в случае BINARY_CHECKSUM, но будут одинаковыми для функции CHECKSUM (при условии, что у нас есть нечувствительная к регистру установка экземпляра). Другое отличие заключается в сравнении выражений. BINARY_CHECKSUM() возвращает одно и то же значение, если элементы двух выражений имеют однотипные и байтовые представления. Таким образом, "2Volvo Director 20" и "3Volvo Director 30" будут давать одинаковое значение, однако функция CHECKSUM() оценивает тип, а также сравнивает две строки и, если они равны, возвращается только одно и то же значение.

Example:
STRING              BINARY_CHECKSUM_USAGE    CHECKSUM_USAGE
------------------- ----------------------    -----------
2Volvo Director 20  -1356512636                -341465450
3Volvo Director 30  -1356512636                -341453853
4Volvo Director 40  -1356512636                -341455363

Ответ 2

HASHBYTES с MD5 в 5 раз медленнее, чем CHECKSUM, я тестировал это на столе с более чем 1 миллионом строк и каждый раз тестировал 5 раз, чтобы получить среднее значение.

Интересно, что CHECKSUM занимает точно такое же время, что и BINARY_CHECKSUM.

Вот мой пост с опубликованными результатами: http://networkprogramming.wordpress.com/2011/01/14/binary_checksum-vs-hashbytes-in-sql/

Ответ 3

Я обнаружил, что столкновение контрольных сумм (т.е. два разных значения, возвращающих ту же контрольную сумму) более распространены, чем кажется большинству людей. У нас есть таблица валют, использующая код валюты ISO как ПК. А в таблице менее 200 строк есть три пары кодов валют, которые возвращают тот же Binary_Checksum():

  • "ETB" и "EUR" (эфиопский Бирр и евро) возвращаются 16386.
  • "LTL" и "MDL" (литовские литы и молдавские лей) возвращают 18700.
  • "TJS" и "UZS" (Somoni и Uzbekistan Som) возвращаются 20723.

То же самое происходит с кодами культуры ISO: "de" и "eu" (немецкий и баскский) возвращают 1573.

Изменение Binary_Checksum() в Checksum() устраняет проблему в этих случаях... но в других случаях это может не помочь. Поэтому мой совет - тщательно проверить, прежде чем слишком сильно полагаться на уникальность этих функций.

Ответ 4

Легко получить столкновения с CHECKSUM(). HASHBYTES() был добавлен в SQL 2005 для улучшения системной хеш-функции SQL Server, поэтому я предлагаю вам также изучить это как альтернативу.

Ответ 5

Будьте осторожны при использовании CHECSUM, вы можете получить ожидаемый результат. следующие утверждения производят одно и то же значение контрольной суммы;

SELECT CHECKSUM (N'这么便宜怎么办?廉价iPhone售价再曝光', 5, 4102)
SELECT CHECKSUM (N'PlayStation Now – Sony startet Spiele-Streaming im Sommer 2014', 238, 13096)

Ответ 6

У меня было несколько "строк", которые возвратили тот же binary_checksum, но другую контрольную сумму. (И не только на нескольких персонажах)

Кажется, для меня слишком случайным для обнаружения изменений в 100% случаев, поскольку мы хотим "поймать", где люди исправляют орфографические ошибки, или в последнем случае "добавить" целую строку текста в поле описания,

Я думаю, чтобы получить 100% -ный удар по изменениям, единственный способ сравнить все поля, требующие проверки.