nbnПроблема в том что доступ в базу есть только на чтение (ничего создавать нельзя) поэтому хэш хотелось делать средствами исключительно SQL. Тщательное изучение IBM SQL Reference показало что встроенного действительно ничего нет, пришлось сделать руками. Вдруг кому пригодится:

Хеш функция четырех аргументов f(a,b,c,d) = ((29*a+b)*29+c)*29+d

Не md5 конечно ... но прокатит
А зачем вообще это нужно? Особенно при условии что писать ничего нельзя.

nbnВозникла такая необходимость при решении задачи интеграции с системой, которая хранит данные используя СУБД информикс. К этой системе доступ есть только на чтение (такова политика безопасности организации заказчика) - то бишь разрешено только исполнение SQL запросов для получения необходимых данных. Гениальный разработчик системы использовал в качестве первичного ключа всех объектов четыре! поля в которых хранятся 5-6 значные числа. Просто слепить 4 поля чтобы получить 20 значный первичный ключ не хотелось - как вариант использование встроенного механизма хеширования, которого в информиксе к сожалению не оказалось.
Возможно я молодой и глупый, но у меня есть заднее чувство что md5 не гарантирует разного хеш для разных аргументов, он вполне может совпасть, аналогично ваша функция.

nbnВ теории совпадение возможно. Но не на подобных данных (последовательности с шагом 1). Если бы данные имели большой разброс - то тут риск конечно бы был (это касается моей функции). Что касается md5 то тут вероятность совпадения еще меньше, только если входные данные сильно больше того что получается на выходе md5 (128 бит). Хотя с другой стороны первичный ключ - не то место где можно допускать хотябы минимальный риск совпадения - поэтому конкатенация самый надежный способ.
Вольному конечно воля, но чем неидеальные 12 байт или 16 байт лучше чем идеальные 24 мне не понятно. Ну я бы еще понял если бы была попытка уложиться в 8 байт. Умножение, а не деление на простое малоразрядное число 29 тоже ясности не вносит.