axdaily: Surrogate keys in AX 2012

[EVGL]

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

[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]

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

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

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

[Logger]

Цитата:

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

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

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

Цитата:

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

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

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

[TasmanianDevil]

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

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

[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;
}

[mazzy]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

[Logger]

Цитата:

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

[fed]

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

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

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

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

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

[Logger]

Цитата:

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

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

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

[gigz]

Цитата:

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

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

Не буду пока точно ничего говорить, так как детально не разбирался с импортом. Разберусь - напишу.

Но из опыта использования создается ощущение, что иморт умеет обрабатывать такие случаи используя метаданные (отношения межуду таблицами, что-то еще?). Тоесть если в импортируемом файле UnitOfMeasure.FromUnitOfMeasure равен какому-то UnitOfMeasure.RecId, то они будут равны и после импорта (хотя и будут другими).

[Logger]

Цитата:

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

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

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

[Logger]

Цитата:

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

Не буду пока точно ничего говорить, так как детально не разбирался с импортом. Разберусь - напишу.

Но из опыта использования создается ощущение, что иморт умеет обрабатывать такие случаи используя метаданные (отношения межуду таблицами, что-то еще?). Тоесть если в импортируемом файле UnitOfMeasure.FromUnitOfMeasure равен какому-то UnitOfMeasure.RecId, то они будут равны и после импорта (хотя и будут другими).

Все верно. Она умеет делать такое перекодирование. Это еще трешка умела. (после импорта берет и перебивает ссылочные значения по recId)


Я же имел в виду немного другое. Чтобы консультант мог при импорте из Excel в поле UnitOfMeasure.FromUnitOfMeasure поставить не значение ссылки по recid, а соответсвующее значение UnitOfMeasure.FromUnitID ну или что там соответствует значению Symbol - поля. А импорт бы его сам перекодировал в ссылку на recid. Вариант Mazzy - хорош, но подразумевает определенную квалификацию в программировании....

[EVGL]

Цитата:

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

Но из опыта использования создается ощущение, что иморт умеет обрабатывать такие случаи используя метаданные (отношения межуду таблицами, что-то еще?). Тоесть если в импортируемом файле UnitOfMeasure.FromUnitOfMeasure равен какому-то UnitOfMeasure.RecId, то они будут равны и после импорта (хотя и будут другими).

Так и раньше было. Пример: заимпортировать таблицу DlvTerm и тексты LanguageTxt к ней. Для это экспортируем обе и импортируем обе разом. AX переделывает ссылки по RecId в LanguageTxt на новые. Если забыть включить LanguageTxt в группу сразу и заимпортировать только DlvTerm - все, поезд ушел.

Интересно будет с импортом из внешних приложенией, где ссылки по RecId заранее не установлены. В текущих версиях AX приходится химичить в Excel или использовать "метод mazzy" (я чаще именно так делаю, поскольку Экселю принципиально не доверяю в отличии от простых текстовых файлов).

[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, для которого предназначена аксапта...

[EVGL]

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

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

[Logger]

Цитата:

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

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

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

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

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