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

[mazzy]

Цитата:

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

По секрету тебе скажу - все системы автоматизированного тестирования являются внешними программами

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

будет ли это внутренней программой (ключевое слово select, класс query на том же самом AOS, запись логов из AOS в отдельную базу как в TraceParser) или внешней программой - не важно. Важен механизм доступа (select/query - один механизм, прямой запрос/connection - другой механизм).

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

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

но чего ни в коем случае не должны делать разработчики - придумывать совсем другой механизм доступа к данным!

[lev]

Цитата:

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

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

полностью согласен! ведь народ который использует эту программу, пользуется механизмами, которые написаны в самой аксапте, на Х++. А не внешними программами, которые написанны (+ ко всему) на других языках.
что собственно mazzy уже не в первом посте пытается донести!

[fed]

Цитата:

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

полностью согласен! ведь народ который использует эту программу, пользуется механизмами, которые написаны в самой аксапте, на Х++. А не внешними программами, которые написанны (+ ко всему) на других языках.
что собственно mazzy уже не в первом посте пытается донести!

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов
Забудтье про клиентов и партнеров - это юнит-тесты. Такого на реальных внедрениях не бывает...

[mazzy]

Цитата:

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

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов
Забудтье про клиентов и партнеров - это юнит-тесты. Такого на реальных внедрениях не бывает...

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

у нас обычно есть настроенная компания-шаблон, в которой по результатам тестирования настройки меняются.

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

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

Если бы встроенный в Аксапту модуль unitTest умел бы работать именно так, то я был бы щастлив.

[lev]

Цитата:

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

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов

Ну например розничная торговля:
Есть сеть магазинов, например 50, есть РЦ. В каждом магазине заказывается товар, возьмем например Масло подсолнечное. Соответственно у каждого магазина примерно известно кол-во потребляемого масла, и по потребностям магазина делается закупка на РЦ. При физ разноске закупки на РЦ автоматом формируются Заказы на Розничного клиента с разными складами (каждый склад, свой магазин).
Так как потребность у магазина постоянно примерно одинаковая (не считая сезонные всплески\падения по отдельным позициям), Вот и получается: "много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов" как то так...

P.S. ещё добавлю. А если магазинов не 50, а 1000 и эти магазины разбиты по менеджерам по 100-штук например. То получаем что 10 пользователей одновременно для 1000 магазинов(клиентов) вставляют записи в таблички salesTable\salesLine

[Evgeniy2020]

а в чем проблема?

если AOT объекты, совместно со всеми настройками,
ключами, RLS, и т.д. переведут в ms sql server

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

это в текущей версии много чего находится в Аксапте,
а если АОТ объекты (application objects)
со всеми конф. ключами, RLS перегонят в MS SQL Server

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

как по мне это классно, вот только если мелкие потоки данных еще как бы нормально. а если проводки за весь период передавать на какого нибудь дохленького клиента, то трфик будет большой.

считать пару строк не проблема. а 10 млн строк ))

тогда это будет немного похоже на 1С подход,
при котором

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

а если большой поток данных, я бы их сначала сильно упаковал бы на сервере ms sql и потом передевал клиента, а если размер слишком большой то данные лучше передавать на АОС,
а тот уже минимальными порциями данные или готовый отчет,

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

а вообще можно было бы сделать обертку и движок на MS SQL
чтобы он веб интерфейс создавал прямо у себя, и клиент получал порцию уже готовую для отображения,

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

а еще можно сделать язык смешанный
c# + T-SQL
такой, что всю бизнес логику можно было бы хранить прямо на сервере MS SQL
тогда клиентов можно сделать весьма тонкими,
а трафик вообще не гонять между AOS - MS SQL
все будет крутится в MS SQL

бизнес логика которая прямо будет в базе хранится,
зачем тогда далеко считывать все, досаточно будет 128 GB ОЗУ
на MS SQL Server там все и крутится и хранится,
и скорость будет зашибительная
почти никакого трафика,

а уже отображения результатов на клиенте,
то есть чуть ли не html поток или xml
тогда клиентом к такой erp
может быть IE, Excel, Biztalk, или некий родной клиент аксапты,

скорости обработки будут высокими,
все метаданные, правила, ключи, rls, application objects будут в MS SQL
будет супер производительность

только при таком подходе сама Аксапта пропадет,
ее переварит MS SQL
получится MS C# SQL Advanced Business Server
то есть MS SQL сервер с оболочкой для разработки и бизнес логикой которая рядом с данными

тогда AX rip

при таком подходе можно будет управлять erp системой с ipad
просо мега сервер 16 процессоров + 128 GB памяти
внутри него и данные и бизнес логика и ключи и rls и olap

а с ipad можно делать что угодно и быстро, и красиво получать любую картинку

Вот если бы меня пригласили архитектором в Редмонд
там бы я напроектировал правильную ERP систему ))

MS SQL + Business logic
Database services
Reporting services
OLAP services
Business logic services (ERP объекты CRM объекты, application logic, conf.keys, seq keys, rls, C# + T-SQL, репозиторий)
Source safe services
Presentation Services (это потоки данных под различных клиентов ie,excel,biztalk,ipad)

я за ))

[George Nordic]

Цитата:

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

а в чем проблема?
если AOT объекты, совместно со всеми настройками,
ключами, RLS, и т.д. переведут в ms sql server
то компоновать правильные запросы там будет не проблема под конкретного пользователя.
это в текущей версии много чего находится в Аксапте,
а если АОТ объекты (application objects)
со всеми конф. ключами, RLS перегонят в MS SQL Server
то я думаю можно сделать движок напрямую который будет считывать
правильно сущности с учетом прав, филдов, rls

бизнес логика которая прямо будет в базе хранится,
зачем тогда далеко считывать все, досаточно будет 128 GB ОЗУ
на MS SQL Server там все и крутится и хранится,
и скорость будет зашибительная
почти никакого трафика,

скорости обработки будут высокими,
все метаданные, правила, ключи, rls, application objects будут в MS SQL
при таком подходе можно будет управлять erp системой с ipad
просо мега сервер 16 процессоров + 128 GB памяти
внутри него и данные и бизнес логика и ключи и rls и olap

Вот если бы меня пригласили архитектором в Редмонд
там бы я напроектировал правильную ERP систему ))

Спаси нас, Господи!

Женя, молодец. Порадовался. Судя по последним веяниям, надо претендовать на роль главного архтектора бизнес - приложений.

Но! Мой Вам совет: Вы уже отстали от жтзни. Нодо все переносить в облако!! И предоставлять он деманд. Да, блин, СОА тоже неплохо аоткнуть - вдруг кто-нить вспомнит!

С Уважением,
Георгий

[fed]

Цитата:

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

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


но чего ни в коем случае не должны делать разработчики - придумывать совсем другой механизм доступа к данным!

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ? Что мы проверим - генерацию recid, способность подставлять dataAreaId в записи, работу RLS ? Стоит ли гемор с работой через .net bc, столь скромных результатов ?
Все равно те данные которые мы читаем и пишем имеют мало отношения к реальности и мало чего позволяют оттестировать. Это же юнит-тест, просто ловушка для глупых ляпов. Тупо табличку записали, потом тупо прочитали...
Комплексного тестирования юнит-тесты не заменяют, и смысла из юнит-теста пытаться сделать универсальный тест и для ядра и для .net bc и для злосчастной логистики я не вижу...
Просто по хорошему после юнит-тестов время от времени должен проходить комплексный тест (уже не автоматический), а живыми людми делаемый. И боюсь как раз с этим-то в разработке аксапты и нехорошо....

[mazzy]

Цитата:

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

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ?

Ты перечитай какие параметры должны учитываться в этом "тупом перенесении данных" и "тупом вынимании"
Выборка данных через AOS vs SQL Server

либо придется генерить кучу наборов данных (во что лично я не верю).
либо использовать таки механизм Аксапты с разные настройками самой Аксапты (хотя бы в вариантах лицензий BE и AM) с одним и тем же набором данных.

Выбор "тупого варианта" автоматически означает, что сильно затруднено тестирование (например, Глобальная адресная книга может быть в вирутальной компании, а может не быть в ней).

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

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