Axapta Report Designer vs. Something

[Андре]

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

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

25000x4 = 100000 запросов

Кроме того на отчет выводятся единицы измерения и название склада - то есть еще по 2 запроса на каждую номенклатуру.

В итого 300000 запросов сейчас и 600000 запросов в ближайшее будущее на каждую построенную оборотку. А теперь представим, что этот отчет запустили сразу несколько пользователей.
В общем отчет строится около 20 минут.

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

Теперь забудем про Аксапту. С помощью любого средства разработки пишем прогу которая посылает на SQL Server эти же четыре запроса, но каждый из них для всей номенклатуры + еще один запрос на join четырех получившихся временных таблиц. Если кого то заинтересует это более подробно, напишите мне - готов объяснить более подробно. Но сейчас суть не в этом. Данная прога строит мне оборотку ровно за 10 секунд. 10 минут и 10 секунд. Есть разница ?

И теперь стою я перед сложным выбором:

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

Хотелось бы услышать Ваше мнение на этот счет. Каким образом Вы получаете отчеты и что Вы думаете насчет построения отчетов не в Аксапте ?

[mazzy]

Буду традиционно нудным

Прежде чем переделывать подумай.
1.
Теоретически, можно сделать один запрос и послать его серверу.
В результате:
1.1. Сервер будет загружен по самое небалуйся
1.2. Пользователь не получит данные до конца выполнения запроса
1.3. Пользователь не сможет прервать исполнение запроса (поскольку он исполняется на сервере)
1.4. Один запрос будет выполняться в рамках одной транзакции (тогда либо тебе придется снизить уровень изоляции) следовательно этот запрос будет блокировать ресурсы, необходимые дргим пользователям
1.5. Загруженный сервер наверняка затормозит работу других пользователей

Это минусы от укрупнения запроса. Внимательно подумай и реши насколько они важны для тебя.

2.
Подумаем немножко.
2.1. Аксапта имеет механизм кэширования. В результате многие запросы не будут посылаться серверу, а исполняться прямо на клиенте. НО для этого запросы должны быть простейшими. Иначе Аксапта не думая отправит их на сервер.
2.2. Механизм кэширования должен помочь с такими запросами как единицы измерения. Может тебе посмотреть на параметры кэширования. Посмотри в профайлере что происходит
2.3. Временные таблицы - это не панацея. Временных таблицы хранятся там, где были созданы. Если сессия исполнялась на клиенте, то временная таблица будет хранится на клиенте со всеми вытекающими последствиями.
2.4. 10 секунд это в монопольном режиме? Ты тестировал свой отчет на реальной загрузке и с реальным количеством блокировок?

3.
Вспомним историю
3.1. Аксапта на самом деле очень древний продукт
3.2. Аксапта никогда не переписывалась "с нуля". Все инкарнации добавляют функциональность и исправляют некоторые явные недочеты. Поэтому в Аксапте содержится код, пришедший еще со старых файл-серверных версий.
3.3. Поэтому вполне возможно, переписывание действительно "драматически" улучшит производительность.

Итог:
Скорее всего, нет однозначных решений.
Подумай, взвесь и прими решение.

[mazzy]

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

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

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

[Андре]

Цитата:

Буду традиционно нудным

Постараюсь соответствовать:

Цитата:

1.1. Сервер будет загружен по самое небалуйся

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

Цитата:

1.2. Пользователь не получит данные до конца выполнения запроса

Можно подумать, что в Аксапте я мог воспользоваться полученными данными до конца выполнения запроса. Пока отчет полностью не построится о работе и речи быть не может.

Цитата:

1.3. Пользователь не сможет прервать исполнение запроса (поскольку он исполняется на сервере)

В Аксапте, при построении отчета Ctrl-Break тоже как правило не работает и прерывать исполнение серии Аксаптовских запросов приходится через Ctrl-Alt-Del и снятие Аксапты из списка выполняемых задач.

Цитата:

1.5. Загруженный сервер наверняка затормозит работу других пользователей

Аналогично пункту 1.1

Цитата:

2.4. 10 секунд это в монопольном режиме? Ты тестировал свой отчет на реальной загрузке и с реальным количеством блокировок?

Да. Это при реальной нагрузке с реальным количеством блокировок.

[Андре]

Цитата:

3.3. Поэтому вполне возможно, переписывание действительно "драматически" улучшит производительность.

По моему многие запросы реализуемые T-SQL просто невозможно реализовать с помощью Акапты. Например вложеные запросы. Как я понял в Аксапте они реализуются с помощью цикла по результатам одного запроса с вызовом второго запроса в теле этого цикла. Отсюда и получается такое большое количество запросов. И ничего средствами Аксапты здесь сделать нельзя.

Цитата:

В стандартном отчете разработчикам пришлось заниматься программированием для того, чтобы обеспечить произвольные комбинации складских аналитик.

Мы используем только одну складскую аналитику и с учетом того, что продукт делается под конкретное предприятие, а не для широкого распространения, то это меня не беспокоит.

Цитата:

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

Не в случае с оборотной ведомостью. Да и вообще я не уверен в упрощении. Насколько я помню, складские аналитики редко выводятся в отчеты.

[komar]

Есть по крайней мере несколько преимуществ использования внешний генераторов отчетов:
1. Возможно более удобные средства формирования дизайна отчетов
2. Возможность получать отчетность по нескольким компаниям без написания специального программного кода
3. Независимость от стандартных классов (и, как следствие, при обновлении версий следить нужно только за структурой БД).
4. Более удобный интерфейс для построения отчетов.
5. Возможно боле удобные средства интеграции с тем же Екселем (обычный отчет из Аксапты в Ексель перекидывается только через текстовый файл, и то с глюками, экспорт в RTF вообще ужасен).
6. Отсутствие потребности в приобретении лицензий Axapta для рабочих мест, являющихся только пользователями отчетов.
7. Отсутствие возможности для таких рабочих мест "сломать" что-нибудь в Аксапте (без каких-либо дополнительных затрат времени на разграничение доступа).

[mazzy]

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

1.3. Ctrl+Break не работает как раз в то время, когда Аксапта ничего не исполняет, а ждет ответа от сервера. В этот момент ее действительно прервать нельзя.

2.4. ОК

3.3. Можно. Стандартно - join. inner join, outer join, exists join, notexistsjoin. Это не совсем вложенные запросы. Но он позволяет выразить многое, не прибегая к вложенным запросам. В query он виден через вложенные datasource. В форме - через JoinSource.

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

Насчет аналитик. Сомневаюсь, что в России может использоваться только одна аналитика. Если она одна, то это должна быть ГТД. А склады?



2 komar
Поясни пожалуйста насчет "Возможность получать отчетность по нескольким компаниям без написания специального программного кода".
А что не устраивает свойство Company в datasource отчета?

[Андре]

Цитата:

Насчет аналитик. Сомневаюсь, что в России может использоваться только одна аналитика. Если она одна, то это должна быть ГТД. А склады?

Нет как раз склады есть, а вот ГТД мы не используем. Как я понимаю это связано с тем, что у нас перерабатывающее производство и мы никогда не продаем то, что приобрели.

[Андре]

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

[macklakov]

а зачем? Если хочешь отработать простой sql запрос, есть классический набор классов:
Connection
Statement
resultSet

[Андре]

Цитата:

а зачем? Если хочешь отработать простой sql запрос, есть классический набор классов:
Connection
Statement
resultSet

Хм... А каким образом полученный resultSet я смогу вывести в отчет ?

[Андре]

select InventTable.ItemId, sum(qty), sum(case when costAmountPosted=0 then costAmountPhysical else costAmountPosted end)+ sum(costAmountAdjustment)

А такую вещь я могу получить одним запросом в Аксапте без использования Statement ?

[macklakov]

Нет, в Аксапте не сможешь. И я не знаю языков, исполняемых на стороне клиента, в которых сможешь. С resultSet работать очень просто.
- в classDeclaration объявляешь
- в init заполняешь
- в executeQuery по next получаешь следующую строку и по getString(real и т.д.) получаешь значение
P.S. А на чем ты раньше писал?

[mazzy]

Цитата:

Изначально опубликовано Андре
sum(case when costAmountPosted=0 then costAmountPhysical else costAmountPosted end)+ sum(costAmountAdjustment)

Вот как раз, чтобы не зависеть от низкоуровневого назначения полей и рекомендуется пользоваться интерфейсными классами. См. Best Practice.

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

[Андре]

Цитата:

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

В смысле ? Есть программа на клиенте. Она посылает запрос серверу, получает recordSet\resultSet\dataSet (это уж где как называется). Ну например на клиенте , написанном на Delphi/Java/C++ я могу послать такой запрос на SQL Server и получить результат.

Думаю, что с помощью классов Connection - Statement - resultSet это тоже возможно.

Цитата:

P.S. А на чем ты раньше писал?

Раньше это когда ? Вообще, или на чем я реализовал оборотную ведомость ?

Цитата:

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

Он уже гарантированно на порядки увеличил производительность

Цитата:

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

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

[glibs]

Цитата:

Изначально опубликовано komar
3. Независимость от стандартных классов (и, как следствие, при обновлении версий следить нужно только за структурой БД).

Что-то мне кажется, что при изменении настроек некоторых функциональных ключей - тоже. Тут нужно еще смотреть на степень вашего консератизма.

[komar]

Свойство datasource не устраивает тем, что плохо представляю себе пользователя, с программированием не знакомого, использующего это свойство при формировании отчета. А я говорил с позиции непрограммиста. Который внешним генератором типа Crystal Reports пользоваться может, а вот свойства переставлять - вряд ли.
А задача составления сводных отчетов стоит. Поскольку знаю, что ты сразу же начнешь рассказывать, где находится консолидация, скажу еще, что не только по финансовому модулю такая здача может стоять.

Насчет использования внешнего генератора - промышленному использованию этого метода в Аксапте мешает только открытый программный код, создающий желание сразу же что-то там наваять. Такие же системы, как Baan или Platinum давно уже фактически сделали Crystal Reports почти что частью программы.
Что каксается Ахапты, то и здесь намечается стойкая тенденция по переходу на более гибкий инструметарий. Пока что в виде формирования отчетов в Excel, OLAP и иже с ними. Во многом из-за того, что лишь немногие отчеты нужны просто для распечатывания на бумаге, да и дизайн отчета легче изобразить в Екселе.

Да и сам Навижн первичку по Основным средствам ваял уже в Excel. Но если первичка точно должна формироваться из системы, то с отчетами это не факт(вспомним тот же модуль стратегического управления, который имеет примочку для просмотра показателей через WEB. Почему же не внешний генератор?)

[Андре]

Цитата:

а зачем? Если хочешь отработать простой sql запрос, есть классический набор классов:
Connection
Statement
resultSet

Попробовал, но почему то даже такой простейший пример работает гораздо медленнее, чем тот же пример на Java и Delphi.

PHP код:


    Connection Con = new Connection();
    Statement Stmt = Con.createStatement();
    ResultSet R = Stmt.executeQuery('Select inventtrans.ItemId, InventTable.ItemName From inventTrans, InventTable where InventTrans.ItemId = InventTable.ItemId');

    while ( R.next() )
    {
      print R.getString(1);
    } 


[macklakov]

to: Андре
quote:
--------------------------------------------------------------------------------
В смысле ? Есть программа на клиенте. Она посылает запрос серверу, получает recordSet\resultSet\dataSet (это уж где как называется).
Думаю, что с помощью классов Connection - Statement - resultSet это тоже возможно.
--------------------------------------------------------------------------------
Я это и имел в виду. Сложные и быстрые запросы пишутся на языке базы, а клиент получает только выборку.

quote:
--------------------------------------------------------------------------------
Раньше это когда ? Вообще, или на чем я реализовал оборотную ведомость ?
--------------------------------------------------------------------------------
В смысле, у тебя, похоже, есть какие-то предпочтения. Интересно узнать, какие еще есть подходы? :-)

[mazzy]

komar,
А ведь точно? в мастере отчетов поля Company нет.
Спасибо.