Насколько я знаю, штатно нельзя средствами Аксапты указать СУБД, что контейнерное поле будет иметь ограниченную длину. Собственно, EDT Sha1HashCode (реализованный, заметьте, в ядре) - это такой своего рода костылик: вроде как поле контейнерное, но в то же время ядро знает, что именно там хранится, и соотв. образом ограничивает длину поля в БД.
В общем случае включать контейнерное поле в кластерный или любой другой индекс - не очень удачная идея. Заметьте, что в стандартном приложении так не делают, вместо этого там используют значение
криптографической хеш-функции от значений "ключевых" полей, получая на выходе значение фиксированной длины. Так сделано и в финансовых, и в складских аналитиках (InventDim).
Собственно, контейнерное поле тут понадобилось потому, что
SHA-1 возвращает 160-битное значение: 20 байт + их обертка в контейнер дали в итоге 28 байт. В случае использования, к примеру,
MD5, которая возвращает 128-битное значение, можно было бы вместо varbinary использовать тип
uniqueidentifier, поскольку GUID также имеет длину 128 бит (16 байт): это позволило бы хранить значение хеш-функции без дополнительной контейнерной "обертки". Но в общем и целом чем больше длина результата хеш-функции, тем меньше вероятность коллизий, поэтому, видимо, предпочтение было отдано SHA-1.