axdaily: Surrogate keys in AX 2012

[S.Kuskov]

Цитата:

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

Коллега уже ругается: отлаживать стало несравнимо труднее. Имеем в дебаггере табличку, а в ней - только RecId. Те, кто имели дело с Global Address Book поймут - теперь вся система такая.

Хм. Интересно тогда, что же они имели в виду под

Цитата:

AX 2012 got kernel support for surrogate key substitution. And not only in forms, but in Axd document services and even in the debugger.

?

[gigz]

[Logger]

Цитата:

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

Коллега уже ругается: отлаживать стало несравнимо труднее. Имеем в дебаггере табличку, а в ней - только RecId. Те, кто имели дело с Global Address Book поймут - теперь вся система такая.

Можно завести в табличке поле с привычным нам ключом, поставить в нем свойство SaveContents - No и на PostLoad() инициализировать его по ссылке. (Инициализацию лучше делать только если взведен какой нить глобальный флажок в Class\Application)
Кривовато, но рабочий вариант. Для отладки сгодится. Я думаю отладчик в 2012-й что-то подобное как раз и делает.

Цитата:

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

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

Надеюсь они дадут возможность ставить в качестве значения поля значение Symbol поля из связанной таблички. С сопутствующим перекодированием при импорте. Будет консультантам счастье. Иначе жесткий ВПР в Excel. По крайней мере нечто подобное для енумов при импорте из шаблона Excel сделано. Даже лукап в Excel сэмулировали

[mazzy]

Цитата:

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

Иначе жесткий ВПР в Excel.

Какой ВПР при импорте? ведь RecID (или другой суррогатный ключ) еще не сущесвует!!!

см. как приходилось импортировать recId раньше (консультант знает только код счета, а системе надо подсунуть recID)
http://axapta.mazzy.ru/lib/import/

Цитата:

Теперь осталось добавить алгоритм, который по коду счета будет находить RecID. Для этого для поля AccountRecID на закладке Исходные тексты программ надо добавить алгоритм

str convert(str input)
{
 
    input = strfmt("%1", LedgerTable::find(input).RecID);
    return input;
}

[Logger]

Цитата:

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

Какой ВПР при импорте? ведь RecID (или другой суррогатный ключ) еще не сущесвует!!!

см. как приходилось импортировать recId раньше (консультант знает только код счета, а системе надо подсунуть recID)
http://axapta.mazzy.ru/lib/import/

Спасибо. Хорошая статья.

Но я немного о другом.
Для того чтобы настроить группу определений как описано у вас, консультант должен уметь программировать или иметь при себе карманного программиста, который на ходу реализует его пожелания. Такое бывает не всегда.

Кто кодировать не умеет - выгружает план счетов в Excel и там колдует со ссылками (превращает ссылки на код счета в ссылки по recId. Естественно это предполагает что план счетов уже импортирован ранее). Я именно это имел в виду когда упоминал про ВПР.

[mazzy]

Цитата:

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

Естественно это предполагает что план счетов уже импортирован ранее). Я именно это имел в виду когда упоминал про ВПР.

О_о!
Остается вопрос - как же консультанту импортировать новые записи

[Logger]

Ух ты !
Классно.

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

1. А где нить есть статьи или публикации почему было принято именно такое решение ? Чем не устроил старый подход ?
2. Где нибудь проводилось сравнительное тестирование по скорости работы по старой схеме и с использованием суррогатных ключей ? В чем выиграли, в чем проиграли ... (Думаю если не было, народ не успокоится и начнет делать это самостоятельно. Я бы сделал. Интересно сравнить)

[TasmanianDevil]

По факту - радует, что наконец-то в недрах MBS собралась критическая масса адекватных людей и разум побеждает маразм. Использование унифицированного по типоразмеру суррогатного ключа в новой архитектуре - это то решение, которое стоит встретить аплодисментами, адресованными Core Team. Остается надеяться, что прикладники не подкачают.

P.S. вот и сделала DAX один шаг вдогонку одной т.н. СОП (нет, mazzy, не 1С ), где 64-битная суррогатина жила и живет с 90-х годов.
P.P.S. Коллеги из партнеров-внедренцев - сочуствую, работы Вам подвалит
P.P.P.S. Российский MBS немного даже жаль и немного даже страшновато - что ж такого от них ожидать в локализации DAX2012

[mazzy]

Цитата:

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

P.P.P.S. Российский MBS немного даже жаль и немного даже страшновато - что ж такого от них ожидать в локализации DAX2012

Надеюсь, что тоже "смены парадигмы"
И тотального рефакторинга!

[mazzy]

Цитата:

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

P.S. вот и сделала DAX один шаг вдогонку одной т.н. СОП (нет, mazzy, не 1С ), где 64-битная суррогатина жила и живет с 90-х годов.

[fed]

У меня такое ощущение, что проектировщики решили пройтись по всем стандартным граблям, на которые наступает бывший системщик, которого ненароком занесло в прикладные программисты:

• Тотальная нормализация
• Модель EAV
• Переход на сурогатные ключи (Когда-то давно придумывал универсальный сурогатный ключ для Clipperа еще).
• Табличное наследование (любимая фишка в проектировании таблиц меня самого лет 15 назад )

В итоге - грошовое увеличение производительности (не везде и не всегда), при заметном усложнении внедрения и поддержки.

Не могу не процитировать самого себя 5летней давности: Microsoft Appoints Nadella to Lead Microsoft Business Solutions

Мысль про системщиков, которых ненароком занесло в прикладную разработку продолжает оставаться актуальной.

[Logger]

Цитата:

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

В итоге - грошовое увеличение производительности (не везде и не всегда), при заметном усложнении внедрения и поддержки.

Почему вы так уверены что будет грошовый прирост производительности ?
Думаю, что уверенно можно говорить только после теста на большом объеме данных. Или ранее уже пробовали ? Поделитесь результатами.

[fed]

Цитата:

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

Почему вы так уверены что будет грошовый прирост производительности ?
Думаю, что уверенно можно говорить только после теста на большом объеме данных. Или ранее уже пробовали ? Поделитесь результатами.

Не пробовал. Но соображения простые:
1. Суррогатный ключ позволят сделать индексные ключи более короткими. А при уменьшении размера ключа с 20 байт до 8 (допустим для custAccount), число индексных входов в странице вырастет в 2,5 раза, соответственно - время доступа упадет в log(x*2,5)/log(x) раз.
2. Аналогичным образом - нормализация. Типа можно сэкономить место на диске за счет снижения избыточности (вынесли, например, из inventTrans часть повторяющихся полей в отдельную табличку).
НО: Я на нескольких своих проектах экспериментировал с сжатием данных, которое появилось в SQL 2008. Так вот на практике, при сжатии популярных (и больших) таблиц, имеющих высокую избыточность и хороший коэфициент сжатия, результирующее время доступа для типичных запросов оставалось прежним (иногда чуть больше, иногда чуть меньше). При этом нагрузка на процессор заметно росла, а число физических чтений с диска падало, но не заначительно. Вывод из этого очень простой: В типичном современном сервере, памяти много (и ее легко добавить), дисковые массивы достаточно быстрые. Поэтому большая часть данных читается из кэша и от размера содержательной части данных зависит не очень сильно (ну конечно - при разумном уровне нормализации). Серьезный выигрыш от уменьшения размера хранимых данных может случиться только если идет запрос, который читает большой объем данных за большой период. Вполне могу поверить что в новой модели данных (или в скомпрессированных таблицах), отчет по inventTrans за 5 лет работает вполне быстрее чем в старой. Проблема в том, что такие запросы обычно гоняются через выделенную OLAP-систему. А в Аксапте наиболее типичный запрос - это джойн 2-3 таблиц, с максимум 50-100 записями в резульируюшей выборке. И если эти 2-3 таблицы, в результате нормализации или введения наследования, превратятся в 5-6, проигрыш от накладняков на джойны и компиляцию более сложного плана запроса заметно перекроют выигрыш от гипотетической экономии на чтении с диска/кэша.

Про EAV тут уже обсуждали, так что не буду повторяться.


Ну и могу заметить что, гм, пожелавшие остаться неназванными источники в Микрософте, рассказывали мне как разработчики ядра (скажем так - системного и ПРИКЛАДНОГО ядра) полировали глюкалу в промежуточных релизах 2012ой и пытались играть с параметрами и структурами данных, в надежде добиться хотя бы той же производительности некоторых операций (например работы с ГК) что и в старой версии. Вроде бы добились. Но любимая glibsом табличка с балансами теперь пересчитывается только по ночам, потому что в онлайне ее быстро обновлять не получается...

Уверен, что в пресс-релизах о выходе DAX2012 будет много сообщений о росте производительности в n раз. Вопрос в том, на какой выборке будет достигнута эта производительность и насколько типична эта выборка для того самого upper midmarket, для которого предназначена аксапта...

[Logger]

Цитата:

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

Уверен, что в пресс-релизах о выходе DAX2012 будет много сообщений о росте производительности в n раз. Вопрос в том, на какой выборке будет достигнута эта производительность и насколько типична эта выборка для того самого upper midmarket, для которого предназначена аксапта...

Именно !
Думаю в этом все дело.
Т.е. вопрос в том на какой рынок хотят вывести Аксапту. У меня складывается ощущение что MS хочет замахнуться на рынок SAP (плох солдат который не мечтает стать генералом. Нафига было вообще лезть на этот рынок, если не стремиться стать на нем лидером ?), т.е. для upper midmarket оставят Navision и может еще что, а Аксапту двинут на крупняк.

Мы с вами свои рассуждения строим для баз размером 10 - 100 - 1000 гигов. (А больше под аксаптой наверно и не бывает пока) А её возможно готовят для больших объемов баз. Тогда понятно желание ввести суррогатные ключи (читай сэкономить память БД и ускорить время работы с индексами).

Кстати, пример про 20 байт не очень удачный. Большинство ключей, по которым идет фильтрация и объединение таблиц являются наследниками EDT NUM, который имеет длину 20 символов, т.е. 40 байт в юникоде. Т.е. разница в 5 раз,а не в 2,5 раза.

[fed]

Цитата:

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

Именно !
Думаю в этом все дело.
Т.е. вопрос в том на какой рынок хотят вывести Аксапту. У меня складывается ощущение что MS хочет замахнуться на рынок SAP (плох солдат который не мечтает стать генералом.

Боюсь - для этого недостаточно введения поддержки суррогатных ключей, наследования таблиц и ивентинга
Для этого надо понимать как клиентский бизнес работает и от этого строить и маркетинг, и продажи, и разработку, и работу с партнерами.А вот в этом направлении движений не намечается. Присутствует наивная вера, что партнеры (у которых не так чтобы уж дофига денег), вдруг вложатся в разработку вертикальных решений и разовьют отраслевую эскпертизу. А раньше они, конечно-же, не хотели этого делать исключительно из за отсутствия суррогатных ключей в Аксапте
Опять улучшения из серии - "They are barking at the wrong tree"

[fed]

Цитата:

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

Кстати, пример про 20 байт не очень удачный. Большинство ключей, по которым идет фильтрация и объединение таблиц являются наследниками EDT NUM, который имеет длину 20 символов, т.е. 40 байт в юникоде. Т.е. разница в 5 раз,а не в 2,5 раза.

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

[Logger]

Цитата:

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

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

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

Кстати по поводу сжатия в SQL 2008 - если не ошибаюсь страницы с индексами он не жмет (в отличие от оракла). Т.е. сжатие не поможет в ускорении работы с индексами. Только сокращение длины ключа.

[fed]

Цитата:

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

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

Типичный прирост БД на типичном внедрении - гигабайт 20-25 в год. Типичный срок жизни внедренной системы (до перевнедрения на новой версии или замены системы) - 4-5 лет. Значит о террабайтных базах можно не особо напрягаться. Ну будет 100 Гигабайт, может 200. Все что выше - не особо типично. Кстати не следует думать что джойн больших таблиц легко происходит. Вполне возможно что тот же inventTrans за 5 лет в новой структуре будет много hash-joinов использовать, которые и память и процессорное время неплохо отъедают.

Цитата:

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

Кстати по поводу сжатия в SQL 2008 - если не ошибаюсь страницы с индексами он не жмет (в отличие от оракла). Т.е. сжатие не поможет в ускорении работы с индексами. Только сокращение длины ключа.

Жмёт-жмёт. Там есть два способа сжатия.
Первый полезен для таблиц в которых много пустых числовых полей (типа inventSum). Он просто в конкретном экземпляре записи динамически усекает все decimals-поля до минимально разумной длины. В результате время вставки и обновления почти такое же как для несжатых данных, а время чтения лучше процентов на 15-20 (но учитывая что с диска данные редко читаются, выигрыш для конкретных запросов не столь велик).
Второй способ - как раз таки традиционный Run Length Encoding, который в Microsoft FoxpPro использовался с 1989 года То есть - поскольку у нас с индексной странице данные отсортированы, то можно не записывать данные как "Иванов","Иванов","Иванов", "Ивановский", а записать "Иванов", 0x6,0x6,0x6"ский".Правда этот способ сжатия хорошо работает, только если у тебя ключи в индексе отсортированы так, что наиболее уникальные поля- в конце списка. Если у тебя индекс с recId начинается, большой выгоды от такого сжатия не будет. Замечу что такой способ сжатия позволяет сильно (типа процентов на 40-60) сэкономить на времени чтения (с диска), но время записи выростает процентов на 15-20, а нагрузка на проц во время записи - еще сильнее.

[EVGL]

Мне тоже разработчики рассказывали об ужасах с производительностью и что справились - довели ее до прежнего уровня.

Справедливости ради надо сказать, что оптимизировать короткие запросы смысла нет. Даме в отделе продаж не очень важно, будет ли ее накладная 12 секунд или 10 разноситься. Для конечного пользователя важны быстрый скроллинг и вменяемое время выполнения сложных отчетов [читай - отчетов по InventTrans :] и процедур (типа закрытия склада или резервирования отгрузки).

[fed]

Цитата:

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

Мне тоже разработчики рассказывали об ужасах с производительностью и что справились - довели ее до прежнего уровня.

Справедливости ради надо сказать, что оптимизировать короткие запросы смысла нет. Даме в отделе продаж не очень важно, будет ли ее накладная 12 секунд или 10 разноситься. Для конечного пользователя важны быстрый скроллинг и вменяемое время выполнения сложных отчетов [читай - отчетов по InventTrans :] и процедур (типа закрытия склада или резервирования отгрузки).

Ну сложные отчеты по inventTrans, это обычно выборка за последний месяц, в котором данных тоже не ахти как много, и большой выгоды от уменьшения объема хранимых данных - нету.
Насчет производительности - очень забавно. Перепроектировали систему для повышения производительности и в итоге понадобилось много релизов и много тестирования для того чтобы с этой самой производительностью справиться и получить тот же результат, который раньше был out-of-the-box.
Интересно - а вот если партнер захочет пару полей в ГК добавить, или аналитику свою, чего тогда с производительностью будет ? И будет ли у партнера лишние человекомесяцы ресурсов и просто месяцы времени для того чтобы с этой самой производительностю "справиться'. Даже в старой модели данных (простой), партнеры регулярно ухитрялись закладывать жуткие грабли в своих доработках, из за которых в микрософт приходили от клиентов телеги по поводу торможения системы. Любопытно - что с партнерскими доработками в новой модели будет.
Еще любопытно - будет ли у локализаторов время и ресурсы на то чтобы протестировать производительность, скажем корреспонденции в новой структуре ГК ?