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

Смотрю сейчас на 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 (для любителей цифирок).

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

[user_ax]

Цитата:

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

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

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

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

Цитата:

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

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

Как писал ранее аналог InventDim.
Благодаря сервисной структуре, мест создания фин. аналитик сравнительно немного и аккуратно добавить заполнение дополнительной таблички не проблема.

Минусы же использования доп таблички типа InventDim традиционны: добавление аналитики необходимо дублировать добавлением поля, что как то некрасиво. Как эту проблему решить пока не придумал. Буду рад если выскажете идеи.