EAV-модель и хэширование.

[fed]

Столкнулся с задачей разработки чего-то, что напоминает о финансовых аналитиках в D365 (конкретно таблицы DimensionAttributeSet/DimensionAttributeSetItem).
Требуется во многие таблицы в разных частях системы засунуть ссылки на некоторый набор аттрибутов. (Табличка эдак полей из 5-6, в среднем на одну сущность вешается порядка 7-10 аттрибутов, но попадаются и вырожденные случаи с 1 аттрибутом или с 400-500).
Моя первая идея состояла в том, чтобы сделать что-то типа клона таблицы DocuRef. Просто добавляем в табличку с аттрибутами refTable и refRecId и живем дальше.
(Пожалуй добавлю - я прекрасно знаю о всех проблемах с моделью EAV. Но здесь она вполне применима, поскольку аттрибуты используются только для просмотра/редактирования пользователем и потом для экспорта в некую внешнюю систему. Запросов по этим данным точно не будет. Можно меня не аггитировать против EAV).

Однако по некотором размышлении, я пришел к выводу что эдак табличка с аттрибутами будет очень уж пухнуть. Аттрибуты прикрепляются к многим записям и при этом еще и часто наследуются и копируются между объектами. Так что могу представить что за год табличка с аттрибутами запросто может вырасти эдак мегабайтов на 300-400. При этом в большинстве случаев, число комбинаций значений аттрибутов - конечное. Вероятно таких комбинаций будет порядка 5-7 тысяч и за год будет прибавляться от силы тысяча.

Появилась идея сделать отдельную табличку, где у меня только два поля - RecId и Hash. Смысл таблички - отдельная уникальная комбинация аттрибутов и их значений. Все остальные таблицы на нее ссылаются по RecId. (То есть - примерно как это со стандартной таблицей DimensionAttributeSet работает).

Когда пользователь просматривает/редактирует аттрибуты, это происходит во временной таблице, куда мы при открытии формы закачиваем релевантные данные из настоящей таблицы аттрибутов. Когда форма закрывается, мы закачиваем содержимое всех значимых полей всех записей на форме в memoryStream и потом рассчитываем из него hash. Если запись с тем же самым hashем нашлась, то мы ничего не записываем, а просто вешаем ссылку на уже существуюшую запись. Если запись не нашлась - создаем новую запись в табличке с комбинациями аттрибутов и потом записываем сами аттрибуты. Потом вешаем ссылочку на новую запись. Если все хорошо работает, то получаем автоматическое сжатие таблицы аттрибутов, поскольку для одинаковых комбинаций аттрибутов записи создаваться не будут.

Возникает два вопроса:

1. Какой способ хэширования лучше всего использовать ? Из тех, которые в D365FO поддерживаются, я думал о SpookyHash, SHA1 и SHA256. Судя по тому что в интернетах пишут, SpookyHash должно хватать, но меня в моем Химикотехнологическом институте вопросам хэширования не учили и я не уверен Приму в дар советы от людей с более программистским образованием .
2. Какова вероятность hash collision, когда для разных message генерируются одинаковые hash ? Просто в DimensionAttributeSet, где кстати spookyHash используется, хранится порядка 15 аттрибутов. У меня могут быть вырожденные случаи, когда хранится эдак 500 аттрибутов (конечно для 98% случаев будет не более 10 аттрибутов хранится и для 99.9% - не более 50 аттрибутов). Высокая скорость хэширования не так важна, я бы сказал что в день будет просматриваться/редактироваться не более 200-300 комбинаций аттрибутов. Так что с точки производительности вполне можно было бы о SHA256/SHA512 использовать.

[axm2017]

Цитата:

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

Появилась идея сделать отдельную табличку, где у меня только два поля - RecId и Hash. Смысл таблички - отдельная уникальная комбинация аттрибутов и их значений. Все остальные таблицы на нее ссылаются по RecId. (То есть - примерно как это со стандартной таблицей DimensionAttributeSet работает).

На одном проекте мои коллеги делали функционал с хэш
нужно было в некой таблице сделать ссылку на разные источники данных с разным набором уникальных полей + возможность восстановления, если вдруг данные пересоздадут.
Решали так же через общую табличку с
+ поле hash
+ дополнительное поле (соль).

Цитата:

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

[*]Какой способ хэширования лучше всего использовать ? Из тех, которые в D365FO поддерживаются, я думал о SpookyHash, SHA1 и SHA256.

Обсуждали для 12 может полезно покажется
Хэш функции Why?
Они использовали md5(возвращает guid) из соображений удобства не более на сколько знаю

Цитата:

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

Судя по тому что в интернетах пишут, SpookyHash должно хватать, но меня в моем Химикотехнологическом институте вопросам хэширования не учили и я не уверен Приму в дар советы от людей с более программистским образованием .[*]Какова вероятность hash collision, когда для разных message генерируются одинаковые hash ?

Низкая (скорее RecId пересекутся имхо), но для надежности коллеги сделали так:

- генерили hash на основе текстового набора имени таблицы + упорядоченных значений полей(это позволяло при необходимости без проблем добавить новое поле) + соль (изначально пустое значение)
- hash был указан как уникальный ключ

- при возникновении ситуации нарушения уникальности ( try catch с исключением duplicateKey) значение соли меняли (банальный счетчик вроде) и повторяли.

Как то так

[mazzy]

Цитата:

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

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

не сочти за троллинг - TextBuffer::strHashKey
возвращает int. очень похоже, что внутри тупой CRC.

Цитата:

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

Какой способ хэширования лучше всего использовать ? Из тех, которые в D365FO поддерживаются, я думал о SpookyHash, SHA1 и SHA256.

поддерживается больше
для dfo365, который работает в облаке, выбрать самый менее нагружающий процессор.
даже если этого не требуется задачей.

[fed]

Цитата:

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

Низкая (скорее RecId пересекутся имхо), но для надежности коллеги сделали так:

- генерили hash на основе текстового набора имени таблицы + упорядоченных значений полей(это позволяло при необходимости без проблем добавить новое поле) + соль (изначально пустое значение)
- hash был указан как уникальный ключ

- при возникновении ситуации нарушения уникальности ( try catch с исключением duplicateKey) значение соли меняли (банальный счетчик вроде) и повторяли.

А есть какая-то статистика по тому, насколько часто у них соль приходилось менять ?

[axm2017]

Цитата:

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

А есть какая-то статистика по тому, насколько часто у них соль приходилось менять ?

По памяти: на несколько миллионов сгенгерированных хэшей - ни разу не видел соль, отличную от пустой. Т.е. у нас коллизий не возникало.

[Владимир Максимов]

А надо ли "хвосты" включать в хеш, если их относительно мало?

Т.е. идея в том, что генерить хеш по первым 10 (50?) атрибутам. А если атрибутов больше, то заранее считать их уникальными. Без сравнения. И для этой цели как раз "соль" и добавлять

[vmoskalenko]

Тут недавно Майкрософт срочно менял SHA1 на SpookyHash. Вот статья https://cloudblogs.microsoft.com/dyn...elease-wave-2/