Хэш функции Why?

Вопрос all?
В 12 используются как минимум два алгоритма hash функций:
sha1
класс DimensionAttributeValueSetStorage
метод getHash

и md5
класс RLedgerTurnoverParamHashKey
метод getHash
и традиционная паранойя не дает покоя с традиционными вопросами почему? и что лучше?

ЗЫ Хэш функции ессно вещь замечательная и соблазнительная и хочется научится их готовить правильно

[Ivanhoe]

Может, потому что второе делала локализация, а первое - центр?

Цитата:

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

Может, потому что второе делала локализация, а первое - центр?

И кого правильнее клеймить позором а кому честь и слава в веках? Индусов или локализаторов?

Ну и конечно SHА1 оно вроде как надежнее, но значит ли это что MD5 дает больше коллизий и реально не стоит даже думать о ней? Ведь люди зачем то заморачивались и явно не спроста.

PS ну и навскидку может кто подскажет какую нибудь стандартную функцию упаковки строки или куда смотреть? Просто есть некие текстовые поля набор которых на вид хорошо бы представить одним полем и по идее обычную строчку с низкой энтропией можно упаковать без особых потерь.

[gl00mie]

Цитата:

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

В 12 используются как минимум два алгоритма hash функций: sha1 \Classes\DimensionAttributeValueSetStorage\getHash
и md5 \Classes\RLedgerTurnoverParamHashKey\getHash
что лучше?

По идее лучше та хэш-функция, которая при прочих равных дает меньше коллизий, а это, как правило, коррелирует с мощностью множества значений функции. С этой точки зрения 128-битное значение MD5 смотрится несколько менее надежным, чем 160-битное значение SHA1. С другой стороны, MD5 до недавнего времени широко использовалась в качестве криптографической хеш-функции, так что для данных в Аксапте ее должно быть более чем достаточно.

Цитата:

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

Ну и конечно SHА1 оно вроде как надежнее, но значит ли это что MD5 дает больше коллизий и реально не стоит даже думать о ней? Ведь люди зачем то заморачивались и явно не спроста.

Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1. У MD5 есть одно огромное преимущество перед SHA1: длина ее значения совпадает с длиной GUID, поэтому его очень удобно хранить в поле типа GUID, наглядно видеть его значение и фильтроваться по нему, в т.ч. в прямых SQL-запросах, потому что GUID - это "родной" тип данных для SQL Server, в T-SQL называющийся uniqueidentifier. Никто ведь не кричит о том, что uniqueidentifier в T-SQL, используемый в тысячах промышленных баз данных, на самом деле не такой уж unique.
На мой взгляд, использование MD5 в Аксапте более чем оправдано: ожидать коллизий на таких смешных для криптографической хеш-функции объемах данных (тысячи наборов финансовых аналитик, миллионы комбинаций складских аналитик) не стоит, а удобство использования типа GUID для хранения значений MD5 подчас бесценно.

Цитата:

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

может кто подскажет какую нибудь стандартную функцию упаковки строки или куда смотреть? Просто есть некие текстовые поля набор которых на вид хорошо бы представить одним полем и по идее обычную строчку с низкой энтропией можно упаковать без особых потерь.

Это нарушение 1-й нормальной формы. Используйте числовые коды вместо строк с низкой энтропией, если хотите сэкономить и повысить производительность.

Цитата:

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

Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1.

В том то и дело что заморачивались. Создали свою отдельно, не используя стандартные возможности от MS.

Цитата:

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

. Никто ведь не кричит о том, что uniqueidentifier в T-SQL, используемый в тысячах промышленных баз данных, на самом деле не такой уж unique.

Так как вероятность совпадения ... В то же время с хэш функциями не все так же просто.

Цитата:

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

Это нарушение 1-й нормальной формы.
.

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

Цитата:

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

Используйте числовые коды вместо строк с низкой энтропией, если хотите сэкономить и повысить производительность.

Нет мне нужно именно эквивалент хэш функции так как данные возможно будут перезаливать. Идеальная хэш функция была бы в самый раз.

[gl00mie]

Цитата:

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

Цитата:

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

Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1.

В том то и дело что заморачивались. Создали свою отдельно, не используя стандартные возможности от MS.

Если вы думаете, что под AX 2012 кто-то озаботился разработкой нового алгоритма криптографической хеш-функции, то глубоко заблуждаетесь - погуглите, алгоритму SHA1 уже 20 лет Кроме того, к разработке алгоритма MD5 Microsoft также не имеет никакого отношения.

Цитата:

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

Так как вероятность совпадения ... В то же время с хэш функциями не все так же просто.

"Паранойя - профессиональное заболевание специалистов по безопасности, но любители могут в этой области зайти гораздо дальше" (с) Банки десятилетиями доверяли электронной подписи, использующей в т.ч. алгоритм MD5, миллиардные транзакции, а тут - вы со своими текстовыми полями...

Цитата:

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

Нет мне нужно именно эквивалент хэш функции так как данные возможно будут перезаливать. Идеальная хэш функция была бы в самый раз.

Не бывает идеальных хеш-функций, другое дело, что под ваши конкретные условия может за глаза хватить того или иного алгоритма. Посмотрите в сторону TextBuffer::strHashKey(), если почему-то считаете, что она вам не подходит, - возьмите ту же MD5.

[George Nordic]

Цитата:

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

Просто есть некие текстовые поля набор которых на вид хорошо бы представить одним полем и по идее обычную строчку с низкой энтропией можно упаковать без особых потерь.

Тогда лишитесь возможности поиска по данным полям.

С Уважением,
Георгий

[Logger]

Ну а как вы тестировали ?
Кстати, тестировать имеет смысл на небольшой длине ключа (порядка килобайта) - так как именно на такой длине вычисляется хеш для inventDim

Цитата:

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

Ну а как вы тестировали ?
Кстати, тестировать имеет смысл на небольшой длине ключа (порядка килобайта) - так как именно на такой длине вычисляется хеш для inventDim

Перебирал 10 000 строк с выработкой хэша вызовом указанных выше функций.

А при чем тут InventDim? У меня другая задача в любом случае строки не мега длины де факто.

Цитата:

Сообщение от George Nordic

Тогда лишитесь возможности поиска по данным полям.

Почему?

1. взял значение полей
2. сгенерил хэш
3 осуществил поиск
4 вуаля

[Logger]

Цитата:

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

Перебирал 10 000 строк с выработкой хэша вызовом указанных выше функций.

Интересно.
А код как работал ?
p-code ?
CIL ?

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

см.
http://blogs.msdn.com/b/mfp/archive/...the-metal.aspx

[George Nordic]

Цитата:

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

Почему?

1. взял значение полей
2. сгенерил хэш
3 осуществил поиск
4 вуаля

Как пользователь стандартными средствами осуществит поиск, если в базе лежит хеш?

Цитата:

Сообщение от George Nordic

Как пользователь стандартными средствами осуществит поиск, если в базе лежит хеш?

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

[Logger]

Как некрасиво.
А мы тут вас всерьез пытаем, как тестили, чего делали.
Бррр.

[George Nordic]

А, понял. Никак тему найти не могу, которая может быть Вам интересна: искусственный vs естественный ключ, там обсуждались преимущества того и другого подхода. А так - да, имеет право на жизнь, особенно если использовать как ключевое поле для связывания таблиц или индекс.

С Уважением,
Георгий

Цитата:

Сообщение от George Nordic

А так - да, имеет право на жизнь, особенно если использовать как ключевое поле для связывания таблиц или индекс.

Ну у нас идея использования хэш родилась по естественным причинам (некоторые данные могут затереть а потом восстановить к примеру), вопрос был только по быстродействию и почему вместо MD5 использовали SHA1. Потестив вопрос снял.

Смотрю сейчас на CustVendSettle на метод checkTransDimension_RU и горько мне от от того что существует еще этот кривой и страшный метод (с точки зрения архитектуры и скорости).

И тянет пофилософствовать а заодно и подумать почему же хэши не использовали внятно в фин. аналитиках и как это сделать за микрософт ибо сопоставления иначе работают медленно а хочется на уровне вжиххх..
ну и традиционное доколе.
Кто чего думает про это?
Можно/нельзя/уже делаю?
Ну и ессно использовать будем лучший и самый быстрый алгоритм SHA1

PS посмотрел на DimensionAttributeValueSet - обрадовался
все уже почти готово оказывается

Жаль нельзя редактировать
Добавлю для тех кому интересно и не очень идеи.
Фин аналитики в частности есть собственно некая структура, представленная в табличках
DimensionHierarchy
DimensionHierarchyLevel
Пример
Аналитика
Структура 1:
1. Важный поставщик
2. Важный ответственный

Структура 2:
1. Важный поставщик
2. ответственный ни очем

Структура 3:
1. Важный поставщик
и т п
и собственно значения:

DimensionAttributeValueSet
DimensionAttributeValueSetItem
Пример
Набор значений 1
1. Важный поставщик: Коля
2 Важный ответственный Вася
3. ответственный ни очем Оля

Набор значений 2
1. Важный поставщик: Коля
3. ответственный ни очем Катя
и т п

Для каждого набора значений DimensionAttributeValueSet вырабатывается хэш по всей совокупности значений DimensionAttributeValueSetItem что позволяет быстренько в случае необходимости их сравнивать и радоваться жизни.

И казалось бы радость близка но к сожалению не все так просто так как мы сравниваем в соответствии со структурой (например ) а они могут и не совпадать
Пример Ищем по Структуре 3

Видимо создатели индусы или их собратья по разуму видели эту проблему и решили ее со свойственной им находчивостью захерачив кучку хэшей в табличку DimensionAttributeValueSet но далее кто-то их уволил либо просто настучал по башке и мысль остановилась на префиксе DEL_

Как же быть?
Вариант видится в том чтобы пойти таки по пути индусов но не до конца: т.е хреначить хэши в соответствии с структурами. Но при этом мы проиграем в скорости в моменте. Чтобы такого не произошло видится мысль создавать их где то в стороне и по ночам пока все спят.
Но правильно ли такое?
Может есть лучше пути-дороги?
Кто сможет решить проблему красиво и так чтобы безвестные кришны в микрософте утерлись от щастья?
Есть ли еще мастера- архитекторы или уже все ушли в поля зеленой энергетики?

Помогите! Подскажите!

Так как традиционно на сложный вопрос ответов нет, отвечу сам:
за счет денормализации ускорили сопоставление раз так в 55 (для любителей цифирок).

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

[Logger]

Может быть вы поподробнее опишете ваше решение с денормализацией ?
Пока не сложилось понимания, что же вы меняли.

Цитата:

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

Может быть вы поподробнее опишете ваше решение с денормализацией ?
Пока не сложилось понимания, что же вы меняли.

Одно из мест где сопоставление будет тупить и тупит однозначно это сравнение фин аналитик. Происходит это за счет возможно красивой но крайне херовой на больших объемах структурой нормализованных аналитик. Так как хотелось как лучше и без напрягов сделали аналог InventDim +- т.е де нормализовали структуру без слома.