AXForum  
Вернуться   AXForum > Прочие обсуждения > forum.mazzy.ru > Обсуждение статей на mazzy.ru
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 18.01.2007, 15:50   #1  
online
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
28,479 / 3359 (168) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Статья посвящена прямым вызовам сервера из программ 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/
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 18.01.2007, 22:50   #2  
glibs_imported is offline
glibs_imported
Участник
 
202 / 10 (1) +
Регистрация: 04.11.2003
IMHO, не достаточно объективный подход в статье. В частности, авторы упускают в статье следующие аспекты.

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

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

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

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

В общем, необходим сбалансированный подход.
Старый 18.01.2007, 23:29   #3  
online
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
28,479 / 3359 (168) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от glibs Посмотреть сообщение
4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД.
Нормально двузвенка масштабируется: Можно устроить кластер из БД.

Согласен, что нужен сбалансированный подход.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 19.01.2007, 11:39   #4  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
Лучший по профессии 2009
SAP
 
1,858 / 1144 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Статья вызвала живой интерес (среди меня, во всяком случае). Чуть позже поизучаю повнимательнее.

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

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

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

Мои "текстовые претензии":
= "вызов EXCEL как COM-объекта через ADO – интерфейс (**); " - Фраза "вызов COM-объекта через ADO–интерфейс" выглядит абсурдно. Excel там вызывается просто как COM-объект ("Excel.Application"), ADO при этом не принимает никакого участия.
= "чтение RECORDSET из EXCEL (**): " - Не "чтение", а "запись" в Excel там демонстируется.
Старый 19.01.2007, 11:45   #5  
Wamr_imported is offline
Wamr_imported
Участник
 
101 / 10 (1) +
Регистрация: 08.01.2004
Согласен с Глебом, однобокая статья. Опасная для неокрепших умов, мечтающих вернуться в любимые среды разработки.

1. К таким запросам сложно прикрутить пользовательские фильтры
2. Проблемы с RLS
3. Всегда надо помнить про DataAreaId
Старый 19.01.2007, 19:01   #6  
Palevo is offline
Palevo
Участник
 
3 / 10 (1) +
Регистрация: 19.01.2007
Следующий шаг после формирования строки sqlConnect может выглядеть так

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

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

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

Согласны с замечанием, что в примере Excel вызывается не через ADO-интерфейс.
Старый 22.01.2007, 11:00   #7  
Palevo is offline
Palevo
Участник
 
3 / 10 (1) +
Регистрация: 19.01.2007
Цитата:
Сообщение от 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 - сервера ни то, ни другое не имеет никакого отношения.
Старый 22.01.2007, 11:22   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
 
3,290 / 1304 (50) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Palevo Посмотреть сообщение
Главной целью выработки стандарта языка является «переносимость» написанных на нем текстов
Как Вы оцениваете трудоемкость переноса отчетов, разработанных по Вашей методике, на другую СУБД по сравнению со стандартными отчетами Axapta?

Цитата:
Поэтому, для того, чтобы быть «кросс-платформным», подъязыку SQL-axapta следует догонять стандарты SQL-92 и SQL-2000, а не оставаться в реликтовых диалектах.
Полагаю, это случится не раньше, чем T-SQL и PL/SQL на 100% реализуют стандарт ANSI (хотя бы ANSI 92). Т.е. никогда
__________________
-ТСЯ или -ТЬСЯ ?
Старый 22.01.2007, 12:13   #9  
Palevo is offline
Palevo
Участник
 
3 / 10 (1) +
Регистрация: 19.01.2007
В название примера 2 внесено исправление.
Старый 23.01.2007, 12:09   #10  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
Лучший по профессии 2009
SAP
 
1,858 / 1144 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Цитата:
Сообщение от Palevo Посмотреть сообщение
В название примера 2 внесено исправление.
Спасибо. А здесь?
Цитата:
Разъяснения и используемые средства:
...
* вызов EXCEL как COM-объекта через ADO – интерфейс (**);
* чтение RECORDSET из EXCEL (**):
...
Старый 23.01.2007, 12:53   #11  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
Лучший по профессии 2009
SAP
 
1,858 / 1144 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Цитата:
Сообщение от 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 '%<значение>%' ).
Старый 01.02.2007, 23:11   #12  
glibs_imported is offline
glibs_imported
Участник
 
202 / 10 (1) +
Регистрация: 04.11.2003
Цитата:
Сообщение от Palevo Посмотреть сообщение
...
Потому, что ее цель – экономия ресурсов клиентской станции, а не повышение эффективности обработки данных.
...
Опять однобоко. Трехзвенка в отличии от двухзвенки способна (в конечном итоге все зависит от разработчика) обеспечивать защиту данных. Двухзвенка этого не делает. Т.е. в трехзвенке возможна реализация контроля доступа на прикладном уровне, причем не на клиенте. В двухзвенке сам клиент имеет "доступ к телу" сервера СУБД. Что как минимум чревато атаками на сервер с самым ценным (т.е. с данными). При работе в трехзвенке сервер с данными может быть далеко запрятан (недоступен снаружи).

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

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

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

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

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

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

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:16.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.