Размерность контейнерного поля Аксапты в БД

[AraraT®]

Коллеги, доброго!

Система - 2012 r3 cu8. СУБД - MSSQL 2014. По сути - виртуалка от Микрософта.

Провел эксперимент. Создал таблицу с 3-мя контенерными полями.
1-е поле без EDT.
2-е поле с EDT - Sha1HashCode
3-е поле с новым EDT типа Container

Смотрим в БД:
FIELD1 (varbinary(max), null)
FIELD2 (varbinary(28), null)
FIELD3 (varbinary(max), null)

В связи с чем возник вопрос: Возможно ли самостоятельно создать EDT типа Container определенного размера? Кто пробовал? Кто что знает по этой теме?

[lvan]

а зачем это надо?

[AraraT®]

Для тех же кластерных индексов, например.

[gl00mie]

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

[Logger]

Интересно, а как быть, если коллизии все же возникнут.
Вероятность этого ненулевая.

[Logger]

Цитата:

Сообщение от AraraT®

Для тех же кластерных индексов, например.

Это антипаттерн в проектировании бд.

https://www.sqlskills.com/blogs/kimb...pace-is-cheap/
https://www.sqlskills.com/blogs/kimb...lustering-key/

В процитированных статьях речь идет о гуидах, но это неважно в данном случае. Важно, что случай с контейнерами аналогичен и будет фрагментация из-за разброса значений криптографических функций.

[dech]

Цитата:

Сообщение от Logger

Интересно, а как быть, если коллизии все же возникнут.
Вероятность этого ненулевая.

Уникального хэша вы не добьётесь никогда. А если добъётесь, то его можно будет преобразовать обратно, и тогда это будет уже совсем не хэш.

[Logger]

Цитата:

Сообщение от dech

Уникального хэша вы не добьётесь никогда. А если добъётесь...

Разве я где-то сказал что хочу добиться уникального хеша ?
Речь о том что не надо делать кластерным индексом выхлоп newguid() и криптографических функций. Об уникальности речь не шла. Кластерный индекс вообще имеет право быть неуникальным.

[dech]

Разговор шел про коллизии, связанные с хэшем. Вы же сами сказали: что делать, если они возникнут? :-) А коллизий меньше будет, если будет больше хэш.
Я согласен, что неуникальный индекс по хэшу можно сделать, но не по varbinary естественно.