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

[Logger]

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

[George Nordic]

Цитата:

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

Почему?

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

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

Цитата:

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

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

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

[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 +- т.е де нормализовали структуру без слома.

[user_ax]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[gl00mie]

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

Цитата:

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

в ходе пром. эксплуатации люди в здравом уме и твердой памяти новые фин.аналитики, как правило, не добавляют.

И в здравом уме и в охренительных штанах.

Бизнес имеет на это право: что то не учли что то стали видеть по другому. Странно будет ограничивать со стороны системы.

Внезапно продолжая тему, хождения по страшному и неизведанному

поделюсь наблюдением, что одна из частей по обработке аналитик сводится к обработке DimensionStorage в savePrivate.

[iCloud]

Да скоро квантовое шифрование будет, че спорить что лучше
https://habrahabr.ru/post/127461/

Цитата:

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

Да скоро квантовое шифрование будет, что спорить что лучше

Байки о квантовом шифровании ходили и в 95 к примеру - толку ноль это чистая теория а пока будут Кузнечики и прочая. Да и в реальности этого за глаза. Взлом дело сложное и другая тема.

А тут реальная задача и проблема: нормально представить фин аналитики.
Классическая нормализация (которой запаривают на собеседованиях выясняя чуть ли не все шесть форм) при больших объемах ожидаемо оказалась отстоем.

Встает вопрос как заменить и при этом сохранить все ништяки

[Ace of Database]

Цитата:

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

Да скоро квантовое шифрование будет, че спорить что лучше
https://habrahabr.ru/post/127461/

https://ru.wikipedia.org/wiki/%D0%9A...81%D1%82%D1%8C

Цитата: " В связи с открытием и успешным тестированием обратимых слабых квантовых измерений основы надёжности квантовой криптографии оказались под большим вопросом[66][67]. Возможно, квантовая криптография войдёт в историю, как система, для которой прототип «абсолютно надёжного» передатчика и прототип перехватчика сообщений были созданы почти одновременно и до начала практического использования самой системы."

Ace of Database и iCloud:
Создайте ветку по интересующей вас теме и страдайте пожалуйста там.

Мне здесь в данной теме интересны мнения по иным тематикам.

ЗЫ если коротко, то не мусорьте.

[Ace of Database]

Судя по фоткам, здесь обсуждается сериал? А я думал тут про шифрование