Хеш строки, чтобы быть определенной длины
Похоже, это проблема с круглыми скобками. Если я понимаю проблему, вам нужно заключить два условия IS NOT NULL в круглые скобки:
SELECT directory.name,
directory.dataid,
m2.LastName,
m3.FirstName
FROM attribute2table
INNER JOIN directory
ON directory.dataid = attribute2table.id
INNER JOIN attribute1table
ON attribute1table.id = directory.dataid
LEFT OUTER JOIN (SELECT max(valstr) AS LASTNAME
FROM attribute1table
WHERE attribute1table.attrid = 2) m2
ON 1 = 1
LEFT OUTER JOIN (SELECT max(valstr) AS FIRSTNAME
FROM attribute1table
WHERE attribute1table.attrid = 3) m3
ON 1 = 1
WHERE directory.dataid = 1290 AND
stringval IS NOT NULL AND
(m2.LASTNAME IS NOT NULL OR
m3.FIRSTNAME IS NOT NULL)
Я также переписал запрос, используя объединения вместо подвыборов, так как я думаю, что это немного яснее.
Также обратите внимание, что в соединениях M2 и M3 я использовал LEFT OUTER с условием 1 = 1, а не с CROSS JOIN, потому что я заметил, что CROSS JOIN действует как INNER JOIN если перекрестный запрос не возвращает строк, то есть весь SELECT не возвращает данных. dbfiddle демонстрирует эту ситуацию здесь
9 ответов
Путем хеши вычисляются, это, к сожалению, не возможно. Для ограничения длины хеша 33 байтами необходимо будет сократить его. Вы могли xor первые и последние 33 байта, поскольку это могло бы хранить больше информации. Но даже с 33 байтами у Вас нет этого большим шанс коллизии.
md5: http://www.md5hashing.com/c++/
btw. md5 составляет 16 байтов, sha1 20 байтов, и sha256 составляет 32 байта, однако как hexstrings, они все удваиваются в размере. Если можно сохранить байты, можно даже использовать sha256.
Больше нет шанса коллизии с подстрокой (sha_hash, 0, 33), чем ни с каким другим хешем, который 33 байта длиной, из-за способа, которым хеш-алгоритмы разработаны (энтропия равномерно распространена в получившей строке).
Если я усекаю 41-байтовый хеш к 33, я был бы, вероятно (конечно!) потерял уникальность.
Что заставляет Вас думать, что у Вас есть уникальность теперь? Да, существует ясно более высокий шанс коллизии, когда Вы только играете с 33 байтами вместо 41, но необходимо быть полностью осведомлены, что коллизии только когда-либо маловероятны, не невозможны для любой ситуации, где имеет смысл использовать хеш во-первых. При хешировании больше чем 41 байта данных существуют ясно более возможные комбинации, чем существуют доступные хеши.
Теперь, ли Вы были бы более обеспеченным усечением хеша SHA-1 или использованием более короткого хеша, такого как MD5, я не знаю. Я думаю, что был бы в более общем плане уверен при сохранении всего хешем, но MD5 знала уязвимости, которые могут или не могут быть проблемой для конкретного приложения.
Вы могли использовать хеш Эльфа (<-C включенный код) или некоторая другая простая хеш-функция как этот вместо MD5 или SHA-X. Они не безопасны, но они могут быть настроены на любую длину, в которой Вы нуждаетесь
Хеши по определению только уникальны для небольшого объема данных (и даже затем это все еще не гарантируется). Невозможно отобразить большой объем информации исключительно на небольшой объем информации на основании того, что Вы не можете волшебно избавиться от информации и вернуть ее позже. Следует иметь в виду, что это не продолжение сжатия.
Лично, я использовал бы MD5 (если необходимо сохранить в тексте), или 256b (32B) хеш, такой как SHA256 (если можно сохранить в двоичном файле) в этой ситуации. Усечение другого хеш-алгоритма для 33B работы также, и МОЖЕТ увеличить возможность генерации хэш-коллизий. Это во многом зависит от алгоритма.
Кроме того, еще одна реализация C MD5, людьми, которые разработали его.
Шанс 33-байтовой коллизии является 1/2^132 (Днем рождения Paradox)
Не волнуйтесь о проигрывающей уникальности.
Обновление: Я не проверял фактическую длину байта SHA1. Вот соответствующее вычисление: коллизия с 32 откусыванием (33 байта шестнадцатеричного числа - 1 символ завершения), происходит только, когда количество хешированных строк становится вокруг sqrt (2^ (32*4)) = 2^64.
Используйте DigestUtils Apache:
Преобразовывает хеш в 32 символьных шестнадцатеричных строки.
Я верю результатам алгоритма хеширования MD5 в 32 числах цифры настолько, возможно, что каждый более подойдет.
Править: к доступу функциональность MD5 должно быть возможно сцепиться в openssl библиотеки. Однако Вы упомянули аппаратные ограничения, таким образом, это может не быть возможным в Вашем случае.