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

[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 систему ))

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

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

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

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