axdaily: Surrogate keys in AX 2012

[fed]

Цитата:

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

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

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

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

[fed]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

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

[fed]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

С этим не поспоришь

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

[Logger]

Цитата:

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

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

Это все верно.
Но я подумал о том что возможно Аксапту готовят для работы в более жестких условиях. Потому что извините - когда у вас полбазы влезает в оперативку сервера БД, то это тепличные условия. Можно вообще про оптимизации не думать, а ковырять в носу весь день.

[gigz]

Цитата:

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

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


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

Ок, тут я тоже пока не очень в теме. Однако, так как AIF тоже поддерживает суррогатные ключи, думаю что все хорошо. Например, есть новый AX plug-in для Excel, который общается с Аксаптой через сервисы. Так вот мне удалось им заимпортировать в Аксапту переводы для единиц измерения не указывая значений суррогатных ключей, только символы.

[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, а нагрузка на проц во время записи - еще сильнее.

[fed]

Цитата:

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

Это все верно.
Но я подумал о том что возможно Аксапту готовят для работы в более жестких условиях. Потому что извините - когда у вас полбазы влезает в оперативку сервера БД, то это тепличные условия. Можно вообще про оптимизации не думать, а ковырять в носу весь день.

Стоимость 4 гигов серверной памяти Kingston - порядка 120 евро. Стоимость работы специалиста по производительности (в Германии) - 120 евро за час
Вообще вся реляционная теория писалась в те времена когда годовая зарплата спеца была в районе 30000, а стоимость VAX средней руки - 500000. Память была дорогой, а диски медленными. Теперь вон, в новой версии Power Pivot (которая в Denali должна быть интегрирована в SQL Server), на полном серьезе собираются почти всю базу держать в оперативке в сжатом виде. Вообще - может оказаться что привычный B-Tree уже не эффективен для хранения данных, потому что данные храняться, как правило, не на диске, а в памяти, и принятое в B-Tree деление на страницы больше не актуально (поскольку чтение идет побайтно, а не постранично).
Это я к тому, что фундаментальные книжки про проектированию БД (Типа Дейта, которого я все равно уважаю), несколько устарели. Соответственно - молиться на все эти нормальные формы и суррогатные ключи - поздновато...

[Logger]

Хм. Раньше не думал про обсуждаемые проблемы в таком ключе. Наверно вы правы.

Но...
К этому сложно привыкнуть.

[S.Kuskov]

Лично я в меньшей степени нормализацию БД связываю с увеличением быстродействия и экономией дискового пространства. Для меня это скорее эволюционный процесс связанный с развитием концептуальной модели системы

http://ru.wikipedia.org/wiki/Нормальная_форма

Цитата:

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

Как отмечает К. Дейт, общее назначение процесса нормализации заключается в следующем:

• исключение некоторых типов избыточности;
• устранение некоторых аномалий обновления;
• разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
• упрощение процедуры применения необходимых ограничений целостности.

[fed]

Цитата:

Сообщение от S.Kuskov

Лично я в меньшей степени нормализацию БД связываю с увеличением быстродействия и экономией дискового пространства. Для меня это скорее эволюционный процесс связанный с развитием концептуальной модели системы

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

[S.Kuskov]

Цитата:

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

Это решается паттерном unit of work. В АХ 2012 он поддерживается достаточно хорошо. Напишу следующий пост про него.

Спасибо за пост axdaily: Unit of Work

[gigz]

Цитата:

Сообщение от S.Kuskov

Лично я в меньшей степени нормализацию БД связываю с увеличением быстродействия и экономией дискового пространства. Для меня это скорее эволюционный процесс связанный с развитием концептуальной модели системы

http://ru.wikipedia.org/wiki/Нормальная_форма

в точку. прямо как будто наши архитекторы это писали

Цитата:

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

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

И еще одно. Инструменты - хорошо, использовать их бездумно - плохо.
В АХ 2012 создано много новых иструментов и предложено много новых парадигм. Но хорошо то, что они введены не слишко насильственно. Можно использовать, а можно и нет. А дальше будет видно, что приживется.

И еще. С# программистов по объявлению набирают в тестировщики

[fed]

Цитата:

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

в точку. прямо как будто наши архитекторы это писали



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

И еще одно. Инструменты - хорошо, использовать их бездумно - плохо.
В АХ 2012 создано много новых иструментов и предложено много новых парадигм. Но хорошо то, что они введены не слишко насильственно. Можно использовать, а можно и нет. А дальше будет видно, что приживется.

И еще. С# программистов по объявлению набирают в тестировщики

Меня больше интересует - как теперь жить с вашей новой ГК ? Ладно, в логистике занормализовали все, но там хоть следы первоначального замысла остались, просто малость перенормализовали содержимое. А над новой структурой таблиц ГК я час медитировал и ничего не понял. Как все это партнеры развивать и поддерживать будут?

[fed]

Цитата:

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

в точку. прямо как будто наши архитекторы это писали

Кстати, где-то в minimsft писали что архитектора Dynamics ERP уволили:http://www.blogger.com/comment.g?pos...p=false&page=3
"A few months back someone made a comment "Lord! Save us from these architects". This is the proof that god exists. Principle Architect of Dynamics team has been let go. There is god after all."

(Просьба не путать архитекторов в разработке и архитекторов MCS )

[gigz]

Цитата:

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

Меня больше интересует - как теперь жить с вашей новой ГК ? Ладно, в логистике занормализовали все, но там хоть следы первоначального замысла остались, просто малость перенормализовали содержимое. А над новой структурой таблиц ГК я час медитировал и ничего не понял. Как все это партнеры развивать и поддерживать будут?

если честно, то не знаю. мне не слишком часто приходится с ГК работать. но в тех случая что приходилось, должен признать, мозг выносило капитально.
но заканчивалось все удачно, находил нужный API.
я очень надеюсь, что будут опубликованы хорошие учебные материалы по новой модели ГК. иначе, конечно, разобраться очень трудно.

[mazzy]

Цитата:

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

Меня больше интересует - как теперь жить с вашей новой ГК ?

fed, не стоит всю ответственность взваливать на gigz.
давай спокойнее.

в этой ветке - обсуждение конкретного текста конкретного блога.