mfp: AX6 sneak preview - SQL AOD

[Blog bot]

Источник: http://blogs.msdn.com/mfp/archive/20...w-sql-aod.aspx
==============
Today we built the first official build of Dynamics AX ever that does not run on AOD files. Starting today Dynamics AX's model database is stored in a Microsoft SQL Server database.

Seen from within MorphX you hardly notice the difference. Everything works as it used to; there are no new feautures; but yet it feels different. The responsiveness of MorphX has slowly been deteriorating as the number of elements in the model has grown over the last releases. Today the speed is back. Navigating the AOT is suddently a pleasure again. Meta data heavy operations, like searching, completes an order of magnitude faster. For example; searching all methods on forms for any text completes in 2 seconds.

But wait a minute; AOD files were not just a database, they were also a deployment vehicle - what is the replacement? Dynamics AX supports a new file format: axmodel-files. (extension: "axmodel", example: "AxSYS.axmodel"). These are binary files, and provides the same deployment capabilites as AOD files did - and yet they are less than half size. Using a new tool you can import/export axmodel files to/from SQL. You can also import AOD files into SQL.

So far we have aimed at providing 1-to-1 parity with AOD files; but the potential of this is amazing - I hardly know where to start...

• Performance can be further improved as the subsystems querying the meta data store starts levarging the powers of SQL. For example; the ISAM database used for the AOD files (and still used by temp tables) doesn't support joins. Due to this many subsystems are overly chatty when reading meta data as they query row-by-row.
• Solving the element ID problem is now possible, as we can leverage the flexibilty and powers in SQL for modifying and extending the model schema.
• Capabilities... There are so many cool scenarios we can enable - but you'll have to wait for an sneak preview after the next milestone to learn more. But to get you thinking: What deployment capabilties did AOD files lack?

To night we celebrate this major achievement with the team.

THIS POST IS PROVIDED AS-IS; AND CONFERS NO RIGHTS.



==============
Источник: http://blogs.msdn.com/mfp/archive/20...w-sql-aod.aspx

[Vadik]

Цитата:

Сообщение от Blog bot

Today we built the first official build of Dynamics AX ever that does not run on AOD files. Starting today Dynamics AX's model database is stored in a Microsoft SQL Server database

Новость похоже прошла незамеченной

[sukhanchik]

Цитата:

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

Новость похоже прошла незамеченной

Просто аглицкий не сразу бросается в глаза...

Только я не понял - а что значит формат SQL?

Цитата:

You can also import AOD files into SQL.

В базу SQL Server что ли все это будет закачиваться?

[Logger]

Цитата:

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

Просто аглицкий не сразу бросается в глаза...

Только я не понял - а что значит формат SQL?


В базу SQL Server что ли все это будет закачиваться?

Походу да. Хранилищем aod файлов станет SQL сервер. Любопытно, временные таблицы они тоже туда запихнут ? А как же интеграция с Oracle ?

[Vadik]

Цитата:

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

Походу да. Хранилищем aod файлов станет SQL сервер. Любопытно, временные таблицы они тоже туда запихнут ?

А зачем? "Запихнуть ради запихивания" разве что.. Учитывая количество кода, использующего временные таблицы и то, как они используются (многочисленные построчные манипуляции) - думаю, нет смысла их куда-то, кроме структур в памяти AOS (или в файлах на нем же) запихивать - иначе получим кучу мелких вызовов AOS - СУБД (и задержек, связанных с сетью)
А зато сколько вкусностей..
- Возможность иметь полноценный во всех смыслах бэкапа (а не "БД по состоянию на 01:00, приложение - на 01:15")
- Про "отзывчивость" приложения уже в оригинальном приложении писали
- Минус один компонент - проще станет (должно стать проще, очень хочется, чтобы стало проще) построение отказоустойчивой системы (то, что имеем сейчас в виде расшаренного приложения, разваливается от малейшей нестабильности сети, и ничего с этим не поделать)
и т.д.

[sukhanchik]

Цитата:

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

А зато сколько вкусностей..
- Возможность иметь полноценный во всех смыслах бэкапа (а не "БД по состоянию на 01:00, приложение - на 01:15")

Мне кажется это мелочи. Мне кажется что не часто можно встретить приложения, которое пользователи (!) модифицируют (ну там отчеты, запросы всякие). А если и есть - то я бы тем более запланировал рестарт аоса для полноценного сохранения их изменений.
А если изменений у пользователей нет - то бекап приложения вполне может делаться по факту его изменения и не привязываться к БД.

Но в целом - да, если приложение "переедет" на SQL Server - то бекап конечно будет более полноценным...

[Logger]

Цитата:

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

А зачем? "Запихнуть ради запихивания" разве что.. Учитывая количество кода, использующего временные таблицы и то, как они используются (многочисленные построчные манипуляции) - думаю, нет смысла их куда-то, кроме структур в памяти AOS (или в файлах на нем же) запихивать - иначе получим кучу мелких вызовов AOS - СУБД (и задержек, связанных с сетью)

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

[fed]

Это, кстати, сделали еще для того чтобы можно было кластеризовать доступ к AOD. Счас-то AOSы и сервер баз данных кластеризовать можно, а вот если у тебя упадет файл-сервер с приложением - то чтобы систему починить - придется руками перенастраивать сервера приложений и тп. Так что получается что сейчас файл-сервер это самое слабое звено при попытке создать надеждную среду для Аксапты.

[Logger]

Цитата:

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

Это, кстати, сделали еще для того чтобы можно было кластеризовать доступ к AOD. Счас-то AOSы и сервер баз данных кластеризовать можно, а вот если у тебя упадет файл-сервер с приложением - то чтобы систему починить - придется руками перенастраивать сервера приложений и тп. Так что получается что сейчас файл-сервер это самое слабое звено при попытке создать надеждную среду для Аксапты.

По факту это давно не проблема. По крайней мере в 3-ке. Можно легко откопировать сколько хочешь одинаковых версий приложений и подключаться каждый аос к своему. Если упадет один файл сервер - пострадает один аос - остальные будут работать.

[gl00mie]

Цитата:

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

По факту это давно не проблема. По крайней мере в 3-ке. Можно легко откопировать сколько хочешь одинаковых версий приложений и подключаться каждый аос к своему.

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