AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.06.2021, 21:22   #1  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
EAV-модель и хэширование.
Столкнулся с задачей разработки чего-то, что напоминает о финансовых аналитиках в 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 использовать.
Старый 24.06.2021, 22:34   #2  
axm2017 is offline
axm2017
Участник
 
1,747 / 292 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от 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) значение соли меняли (банальный счетчик вроде) и повторяли.

Как то так

Последний раз редактировалось axm2017; 24.06.2021 в 22:49.
За это сообщение автора поблагодарили: fed (5), EVGL (3).
Старый 25.06.2021, 07:43   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Вероятно таких комбинаций будет порядка 5-7 тысяч и за год будет прибавляться от силы тысяча.
не сочти за троллинг - TextBuffer::strHashKey
возвращает int. очень похоже, что внутри тупой CRC.

Цитата:
Сообщение от fed Посмотреть сообщение
Какой способ хэширования лучше всего использовать ? Из тех, которые в D365FO поддерживаются, я думал о SpookyHash, SHA1 и SHA256.
поддерживается больше
для dfo365, который работает в облаке, выбрать самый менее нагружающий процессор.
даже если этого не требуется задачей.
__________________
полезное на axForum, github, vk, coub.
Старый 25.06.2021, 09:48   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Низкая (скорее RecId пересекутся имхо), но для надежности коллеги сделали так:

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

- при возникновении ситуации нарушения уникальности ( try catch с исключением duplicateKey) значение соли меняли (банальный счетчик вроде) и повторяли.
А есть какая-то статистика по тому, насколько часто у них соль приходилось менять ?
Старый 25.06.2021, 10:19   #5  
axm2017 is offline
axm2017
Участник
 
1,747 / 292 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от fed Посмотреть сообщение
А есть какая-то статистика по тому, насколько часто у них соль приходилось менять ?
По памяти: на несколько миллионов сгенгерированных хэшей - ни разу не видел соль, отличную от пустой. Т.е. у нас коллизий не возникало.
Старый 25.06.2021, 20:59   #6  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
А надо ли "хвосты" включать в хеш, если их относительно мало?

Т.е. идея в том, что генерить хеш по первым 10 (50?) атрибутам. А если атрибутов больше, то заранее считать их уникальными. Без сравнения. И для этой цели как раз "соль" и добавлять
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 28.06.2021, 17:05   #7  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
145 / 334 (12) ++++++
Регистрация: 25.01.2007
Адрес: Toronto
Тут недавно Майкрософт срочно менял SHA1 на SpookyHash. Вот статья https://cloudblogs.microsoft.com/dyn...elease-wave-2/
За это сообщение автора поблагодарили: Logger (3).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Функциональная модель Логическая схема Koki DAX: Функционал 15 17.10.2010 20:19
Новая модель для Report Builder propeller DAX: Программирование 6 14.04.2010 11:38
Объектная модель Word и Excel miklenew DAX: База знаний и проекты 0 30.05.2007 15:37
ER-модель (или информационная) модуля "Управление запасами" garis DAX: Функционал 4 16.05.2007 13:11
Product Builder: "Модель продукции не существует" Hamster DAX: Функционал 4 17.03.2004 17:46
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.