Показать сообщение отдельно
Старый 16.02.2015, 11:47   #4  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Насколько я знаю, штатно нельзя средствами Аксапты указать СУБД, что контейнерное поле будет иметь ограниченную длину. Собственно, EDT Sha1HashCode (реализованный, заметьте, в ядре) - это такой своего рода костылик: вроде как поле контейнерное, но в то же время ядро знает, что именно там хранится, и соотв. образом ограничивает длину поля в БД.
В общем случае включать контейнерное поле в кластерный или любой другой индекс - не очень удачная идея. Заметьте, что в стандартном приложении так не делают, вместо этого там используют значение криптографической хеш-функции от значений "ключевых" полей, получая на выходе значение фиксированной длины. Так сделано и в финансовых, и в складских аналитиках (InventDim).
Собственно, контейнерное поле тут понадобилось потому, что SHA-1 возвращает 160-битное значение: 20 байт + их обертка в контейнер дали в итоге 28 байт. В случае использования, к примеру, MD5, которая возвращает 128-битное значение, можно было бы вместо varbinary использовать тип uniqueidentifier, поскольку GUID также имеет длину 128 бит (16 байт): это позволило бы хранить значение хеш-функции без дополнительной контейнерной "обертки". Но в общем и целом чем больше длина результата хеш-функции, тем меньше вероятность коллизий, поэтому, видимо, предпочтение было отдано SHA-1.
За это сообщение автора поблагодарили: NetBus (1), AraraT® (4), dech (3).