Выборка данных через AOS vs SQL Server

[fed]

Цитата:

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

возвращаемся к первоисточнику

про BC в первоисточнике ничего не было

В общем, пусть идут в пень со своими заморочками насчет производительности.
Если есть проблемы с производительностью, то не надо нам подсовывать workaround через прямые запросы к SQL.

Проблемы с производительностью надо выявлять. А не заметать под коврик прямыми запросами в SQL. ТОЧКА.
Проблемы с производительностью надо править в ядре и в стандартном функционале теми же средствами, которые юзают клиенты и партнеры. ТОЧКА.

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Дык вот для шагов 3,4 и (вероятно) 1 - .net bc и непрямой SQL не нужен совсем, если Ваньку начальство заставляет .net bc использовать для чтения базы на шагах 3 и 4 - это верх изврата.

[mazzy]

Цитата:

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

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Замечательно.
Только пусть не на C#, а на X++.
В Аксапте же есть замечательный модуль UnitTesting.

Что-что? Фиговый, говоришь? В нем не хватает функционала, говоришь? Не хватает средств интеграции с VS, говоришь?

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

Проблема одна: разработчики должны получать и исправлять те же самые баги, что и клиенты.
Если система тестирования работает с абсолютно другим механизмом доступа к данным, то с огромной вероятностью разработчики получат другой набор багов. В результате исправят не все баги, которые видят обычные клиенты. Что лично меня - не устраивает.

[sukhanchik]

Цитата:

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

Ну, дык пусть дорабатывают модуль, суки.

Злой ты. Но справедливый.

Если честно - я поэтому и спросил - что это такое. У меня ж в голове не укладывался тот факт, что тестировать систему можно не на самой системе. Это операционные системы пофиг на каком языке (C#, X++, VBA) тестировать. А тут-то вся фишка в коде. Если какая-нибудь функция ядра (FormDataSource.findRecord() к примеру) тормозит на больших объемах - то либо нужно рекомендовать обходной вариант (Best Practice), либо исправить в ядре, если это возможно. Сделали ж класс RecordInsertList для быстрой вставки данных. Вряд ли его тестировали "извне" .

А тут-то.... что-то из ядра не работает на большом объеме данных. И кто это проверит?
А с индексами меня вообще все умилило. Как можно тестировать алгоритм (скорость работы которого напрямую зависит от наличия правильных индексов) - не заморачиваясь на конфигурационные ключи? Предполагать что такой индекс есть, не зная о том, что у пользователя нет такого индекса? Или сразу, независимо от суммы оплаты давать пользователям лицензии на все, что есть в АХ? (т.к. тестируется только полная версия АХ, которой наверняка не стоит ни у одного клиента).

[nix0root]

Плюс прямых запросов при работе с Oracle это Hints.
Через AOS "подпихнуть" хинты мне так и не удалось