Об альтернативном программировании SQL-сервера в Dynamics AX

[mazzy]

Статья посвящена прямым вызовам сервера из программ X++ без применения SQL-запросов Dynamics AX (ранее известная как AXAPTA). Это позволяет превратить Dynamics AX в клиент-серверную систему и получить преимущества за счет распределенной обработки данных: повышение скорости обработки, разгрузку вычислительного комплекса. Кроме того, за счет использования в прямых запросах к серверу современных реализаций языка SQL, таких как Transact-SQL для MS SQL или PL/SQL для ORACLE (вместо ограниченного варианта SQL Dynamics AX), достигается большая гибкость и эффективность обработки данных. Приводятся примеры построения отчетов, процедур вставки и модификации данных. В статье речь идет о версиях Dynamics AX до 3.0 SP5 включительно.

Подробнее...
http://axapta.mazzy.ru/lib/direct_sql/

[glibs_imported]

IMHO, не достаточно объективный подход в статье. В частности, авторы упускают в статье следующие аспекты.

1. Двухуровневая архитектура клиент-сервер, которая так ярко описывается в статье, в настоящее время уже устарела. И ей на смену пришла трехуровневая.

2. Одним из факторов не использования хранимых процедур и примитивного SQL является кросс-платформенность.

3. Для OLTP систем тяжелые процедуры и тяжелые SQL-запросы в совокупности с тяжелыми триггерами не всегда оптимальны. Могут возникнуть тяжелые блокировки, что будет тормозить работу пользователей на OLTP операциях. Чем больше пользователей в системе — тем актуальнее проблема. Альтернативный подход к решению проблемы можно посмотреть в Аксапте в процедуре многопользовательского закрытия склада.

4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД. Либо делать распределенные БД. Последнее далеко не всегда приемлемо или эффективно. А отдача от дополнительных вложенных ресурсов в одну коробку имеет тенденцию к снижению, начиная с определенного предела. То же самое касается большого количества машин в кластере. Сервера приложения масштабировать легче, а при их использовании нагрузка на ресурсы серверов БД снижается.

В общем, необходим сбалансированный подход.

[mazzy]

Цитата:

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

4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД.

Нормально двузвенка масштабируется: Можно устроить кластер из БД.

Согласен, что нужен сбалансированный подход.

[Gustav]

Статья вызвала живой интерес (среди меня, во всяком случае). Чуть позже поизучаю повнимательнее.

Пока же бросилась в глаза некоторая незаконченность примеров 1 и 2. Хочется спросить "А дальше что?", т.е. хотелось бы увидеть еще несколько шагов, например, куда далее следует подставлять sqlConnect.

Особенно "незакончен" пример 2: там фактически инициализируется Excel и потом вызывается метод CopyFromRecordset для ЗАПИСИ (!) в Excel recordset'а rs, который непонятно откуда должен возникнуть.

Подчеркиваю еще раз - "для ЗАПИСИ", а не для "чтения RECORDSET из EXCEL" как это написано в заголовке примера.

Мои "текстовые претензии":
= "вызов EXCEL как COM-объекта через ADO – интерфейс (**); " - Фраза "вызов COM-объекта через ADO–интерфейс" выглядит абсурдно. Excel там вызывается просто как COM-объект ("Excel.Application"), ADO при этом не принимает никакого участия.
= "чтение RECORDSET из EXCEL (**): " - Не "чтение", а "запись" в Excel там демонстируется.

[Wamr_imported]

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

1. К таким запросам сложно прикрутить пользовательские фильтры
2. Проблемы с RLS
3. Всегда надо помнить про DataAreaId

[Palevo]

Следующий шаг после формирования строки sqlConnect может выглядеть так

CCADOConnection ccADOConnection;
;
ccADOConnection = new CCADOConnection();
ccADOConnection.open(sqlConnect);

В примере 2 инициализируется Excel как CОМ- объект.
ADO-интерфейс используется на предыдущем шаге для получения стандартного ADO-Recordset-a, содержащего выборку с SQL-сервера.

Этот стандартный RecordSet читается методом Ехсеl CopyFromRecordset, который подразумевает и чтение из объекта RecordSet, и запись в указанный объект Ranges.

Согласны с замечанием, что в примере Excel вызывается не через ADO-интерфейс.

[Palevo]

Цитата:

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

1. Двухуровневая архитектура клиент-сервер, которая так ярко описывается в статье, в настоящее время уже устарела. И ей на смену пришла трехуровневая.

Трехуровневая схема или в просторечии «трехзвенка» еще называется «тонкий клиент». Почему? Потому, что ее цель – экономия ресурсов клиентской станции, а не повышение эффективности обработки данных. Девиз трехзвенки – «работать в axapta с мобильного телефона». В пределе, трехзвенка превращает локальную сеть компьютеров в мультитерминальный комплекс. Вычислительные ресурсы N – компьютеров (клиентских станций) заменяются ресурсами всего одного компьютера (сервера приложений). Если производительность этого компьютера имеет тот же порядок, что клиентская станция, то эффективность обработки данных не увеличивается, но падает в N – раз!
Алгоритмы же обработки данных, к которым наши основные претензии, одинаковы, что в трехзвенке, что в двухзвенке, как и сказано в статье.

Цитата:

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

2. Одним из факторов не использования хранимых процедур и примитивного SQL является кросс-платформенность.

Главной целью выработки стандарта языка является «переносимость» написанных на нем текстов. Поэтому, для того, чтобы быть «кросс-платформным», подъязыку SQL-axapta следует догонять стандарты SQL-92 и SQL-2000, а не оставаться в реликтовых диалектах.

Цитата:

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

3. Для OLTP систем тяжелые процедуры и тяжелые SQL-запросы в совокупности с тяжелыми триггерами не всегда оптимальны. Могут возникнуть тяжелые блокировки, что будет тормозить работу пользователей на OLTP операциях. Чем больше пользователей в системе — тем актуальнее проблема. Альтернативный подход к решению проблемы можно посмотреть в Аксапте в процедуре многопользовательского закрытия склада.

Во-первых, мы не утверждаем, что «альтернативное программирование сервера» всегда оптимально. Мы указали в статье ряд задач, в основном пакетной обработки, когда оно дает очевидную выгоду. Во-вторых, обращения axapta к базе данных заканчиваются тем же самым стандартным SQL, реализованным на сервере, и с успехом могут быть источником «тяжелых блокировок» при неудачном программировании. В-третьих, мы считаем, что близкий к оптимальному код может быть написан и на существующем подъязыке SQL – axapta, только стиль программирования должен быть другим.

Цитата:

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

4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД. Либо делать распределенные БД. Последнее далеко не всегда приемлемо или эффективно. А отдача от дополнительных вложенных ресурсов в одну коробку имеет тенденцию к снижению, начиная с определенного предела. То же самое касается большого количества машин в кластере. Сервера приложения масштабировать легче, а при их использовании нагрузка на ресурсы серверов БД снижается.

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

[Vadik]

Цитата:

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

Главной целью выработки стандарта языка является «переносимость» написанных на нем текстов

Как Вы оцениваете трудоемкость переноса отчетов, разработанных по Вашей методике, на другую СУБД по сравнению со стандартными отчетами Axapta?

Цитата:

Поэтому, для того, чтобы быть «кросс-платформным», подъязыку SQL-axapta следует догонять стандарты SQL-92 и SQL-2000, а не оставаться в реликтовых диалектах.

Полагаю, это случится не раньше, чем T-SQL и PL/SQL на 100% реализуют стандарт ANSI (хотя бы ANSI 92). Т.е. никогда

[Palevo]

В название примера 2 внесено исправление.

[Gustav]

Цитата:

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

В название примера 2 внесено исправление.

Спасибо. А здесь?

Цитата:

Разъяснения и используемые средства:
...
* вызов EXCEL как COM-объекта через ADO – интерфейс (**);
* чтение RECORDSET из EXCEL (**):
...

[Gustav]

Цитата:

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

1. К таким запросам сложно прикрутить пользовательские фильтры
2. Проблемы с RLS
3. Всегда надо помнить про DataAreaId

к этому от себя добавлю собственную цитату с AxForum'а из этой темы:

Цитата:

...........
2. Поля дат - пустые с точки зрения Аксапты = 01.01.1990 с точки зрения SQL Server
3. Содержимое контейнерных полей будет недоступно
4. Енумы будут числами (для представления их "словами" можно сваять в БД дополнительный справочник всех енумов)
5. В случае Oracle надо будет еще бороться с пустыми строками, выглядящими как Chr(2).
6. В случае Oracle я бы еще добавил, что нужно будет следить за регистром символов (особенно в условии WHERE).
7. Для любой СУБД нужно будет иметь в виду ситуации, связанные с использованием текстовых кодов (всякие id, accountnum и т.п.), выравненными по центру или по правому краю, когда в том же условии WHERE строку-фильтр нужно будет начинать слева некоторым количеством пробелов, которое не всегда очевидно (либо использовать славящийся своей неоптимальностью оператор LIKE '%<значение>%' ).

[glibs_imported]

Цитата:

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

...
Потому, что ее цель – экономия ресурсов клиентской станции, а не повышение эффективности обработки данных.
...

Опять однобоко. Трехзвенка в отличии от двухзвенки способна (в конечном итоге все зависит от разработчика) обеспечивать защиту данных. Двухзвенка этого не делает. Т.е. в трехзвенке возможна реализация контроля доступа на прикладном уровне, причем не на клиенте. В двухзвенке сам клиент имеет "доступ к телу" сервера СУБД. Что как минимум чревато атаками на сервер с самым ценным (т.е. с данными). При работе в трехзвенке сервер с данными может быть далеко запрятан (недоступен снаружи).

На примере той же Аксапты хорошо это просматривается (3-я версия работает в режиме толстого и "полутонкого" (в смысле не классический mainframe терминал) клиента).

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

В общем, я не сторонник терминалов, а сторонник распределения обработки информации по трем узлам (хранилище - прикладной сервер - клиент).

При таком подходе можно выиграть на трафике.

И последний для вас пример. Решает ли (упростим формулировки в предложениях) MS SQL (пусть будет с использованием T-SQL) задачи построения сложной отчетности? А для чего тогда MS выпустил OLAP?

PS. Я сам довольно часто использую прямые запросы к базе. Практически всегда работает быстрее. Но в базе в таких случаях я, как правило, работаю один. А запросы использую для решения аналитических задач, чаще разового характера. (Чтобы никто не подумал, что я враг SQL).

[mazzy]

По теме статьи см. также:
http://axforum.info/forums/showthread.php?...0086#post130086
http://axforum.info/forums/showthread.php?...0321#post130321