-1
Я работаю с SQL Server 2012 и иметь таблицу с полем определяется как:T-SQL функции HASHBYTES и сверка
NVARCHAR (32)
но нужно хранить в нем
NVARCHAR (1024)
значение, и я не в состоянии изменить длина столбца.
У меня есть процедура, которая заполнит это поле. В то же время он будет «делать что-то», если есть поле с таким значением и «ничего не делать», если есть поле с таким значением.
Чтобы решить проблему с длиной я решил использовать HashBytes функцию следующим образом:
DECLARE @HashThis nvarchar(1024);
SELECT @HashThis = CONVERT(nvarchar(1024),'dslfdkjLK85kldhnv$n000#knf');
SELECT HASHBYTES('SHA1', @HashThis);
GO
Я прочитал, что в зависимости от вашей сортировки базы данных вы можете иметь различный хэш возврат для тех же значений. Итак, есть ли способ указать сортировку только для функции, чтобы она не зависела от сопоставления базы данных.
Кроме того, что-то не так с моей идеей?
Я не понимаю ваш вопрос. В чем проблема с использованием более длинного типа данных? Можете ли вы опубликовать код, который показывает вашу проблему, а не ваше решение? – Pondlife
У меня есть стол со столбцом «a», который является nvarchar (32). Во всяком случае, мне нужно сохранить в нем данные, для которых требуется больше места, и мне не разрешено изменять таблицу. Поскольку эти данные будут использоваться только для сострадания, я решил использовать его. Когда он хэшируется, он меньше, но я хочу знать, могу ли я столкнуться с любыми проблемами, потому что раньше я делал что-то подобное. – gotqn
Я думаю, вы можете быть смущены тем, что делает хэш: он не сжимает данные, и нет возможности «перевернуть» хэш, чтобы вернуть исходное значение снова. В Википедии есть [хороший обзор] (http://en.wikipedia.org/wiki/Hash_function) хешей и для чего они используются. Я думаю, вам нужно пересмотреть свой подход здесь, не совсем понятно, что вы делаете, но нет возможности разместить 1024 символа на 32 символа. – Pondlife