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

[kashperuk]

У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария).

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

Недостатки SQL:
- Не учитывает настроек безопасности (особенно RLS)
- Проблемы с генерацией RecId при необходимости вставки данных

Недостатки AOS:
- Медленнее

[MikeR]

Плюс к тому же надо всегда протягивать идентификатор компании.
Ну и не видно кто таки создал запись.
Но скорость.. в третьей версии на порядки отличалась.

[AndyD]

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

Насчет RLS - если запросы выполняются через select, то о его включении надо заботиться дополнительно. Что не всегда делается.
Опять же - для валидации зачем нужны настройки доступа?

[Владимир Максимов]

Ну, собственно, прямые SQL-запросы пишутся именно по той причине, что выборка через AOS слишком медленно. А из недостатков, еще добавлю

- Не все настройки физически хранятся в таблицах на SQL-сервере. Часть настроек находится только на AOS. Например, Base Enum

[MikeR]

тут еще такой неявно-замалчиваемый момент есть, это архитектура модификаций.
Если связи построены криво, и нужен left outer join, то опять надо в базу лезть, что б данные получить.

[Wamr]

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

[Logger]

Цитата:

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

У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария).

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

Недостатки SQL:
- Не учитывает настроек безопасности (особенно RLS)
- Проблемы с генерацией RecId при необходимости вставки данных

Недостатки AOS:
- Медленнее

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

Или разработчики в Майкрософт на такие мелочи уже давно не обращают внимания ?

[kashperuk]

Цитата:

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

Или разработчики в Майкрософт на такие мелочи уже давно не обращают внимания ?

no comments.

[Logger]

Неужели его все таки похоронили в последних версиях Аксапты ?

[AK-76]

Почему же, 2009sp1 + 10g вполне мирно сосуществуют.

В директ запросах надо помнить про то, что CI требует nls_lower(), а правое выравнивание некоторых типов соответственно substr().

[ice]

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

[sukhanchik]

Цитата:

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

через SQL
- привязка к текущей модели данных, добавление/удаление/отключение столбцов и запрос надо править.

Кстати - да - права доступа / конфигурационные ключи / лицензии - вся эта информация есть только в АХ.
Еще момент. Названия таблиц / полей в АОТ и в БД - вообще говоря могут отличаться (если длина названия больше 30 символов).

А что значит "данные выбираются для валидации"? Типа закрыли склад и сделали выборку - все ли пересчиталось?

[kashperuk]

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

[egorych]

Для прямого запроса через ADO/ODBC нужно на клиенте иметь настроенные драйвера и права на подключение к серверу.
Или запрос делаете на AOSе ?

[fed]

Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.
Ведь для того тестовые скрипты и написали на C# чтобы не создавать проблем "квантового порядка", когда тестовые скрипты на X++ сами изменяют наблюдаемую среду. А получается что вы сначала все тестовые скрипты написали на C#, а потом сами же свою идею ломаете....

[mazzy]

Цитата:

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

Выборка через АОС или выборка напрямую из SQL Server

(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария).

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

Недостатки SQL:
- Не учитывает настроек безопасности (особенно RLS)
- Проблемы с генерацией RecId при необходимости вставки данных

Недостатки AOS:
- Медленнее

Недостатки SQL:
= не учитывается кэширование, которое выполняет Аксапта. (что очень плохо)
= не учитывается метод postLoad (правда он уже устаревший), но все равно он используется в LedgerTrans. Также некоторые его используют для логов
= не учитываются display-методы и вообще методы у таблиц
= если пользоваться recordset'ом, то прямой доступ к SQL теряет информацию о типах
= не учитываются виртуальные компании.
= не учитываются свойство (общих таблиц)
= (!) не учитываются конфигурационные и лицензионные ключи (в результате, прямой запрос в SQL должен сам определять какие поля/таблицы есть, а каких нет и перестраиваться на ходу. Обрати внимание сколько труда положили на OLAP кубы, сколько новых объектов в АОТ ввели (перспективы и датасеты) и сколько документов написали на эту тему. Универсальный обработчик с прямым доступом - безумно сложная штука. Если на конкретном проекте с конкретным набором ключей его сделать легко, то в общем случае - не знаю... очень велика вероятность, что накосячат.
= (!) не учитываются конфигурационные и лицензионные ключи на индексах. Со всеми вытекающими для уникальности...
= прямой доступ и доступ через SQL по разному общаются с Array-полями. Array-поля у клиентов используются не только в аналитике. Клиенты делают и свои array-поля. при прямом доступе с большой вероятностью можно накосячить в них
= прямой доступ должен знать о настройках выравнивания (влево-вправо) и корректно работать с ними
= прямой доступ должен знать о настройках Case и корректно работать с этим параметром.
= прямой доступ должен знать о настройках часового пояса в каждой компании (включая виртуальные), если прямой доступ работает с UTC-полями.
= если речь идет о проверках, то не учитываются validateField и validateWrite, в которых написано огромная часть бизнес-правил.
= если в результате проверок будут выполняться какие-то автокоррекции, то при прямом доступе к SQL идут лесом все аксаптовские database логи, все update, и даже doUpdate (на которые программисты очень сильно надеются как на последнее средство контроля)
= если в результате проверок будет хоть как-то меняться схема (добавляться поля, индексы, изменяться длина полей), то очень велика вероятность рассинхронизации и очень велика верояность, что прямой доступ сделает схему, которую нельзя прочитать в самой Аксапте (например, не хватает буфера)

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

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

в общем, тестирование и исправление должно работать при помощи тех же средств, которые используются нормальными клиентами. В противном случае велика вероятность того, что с точки зрения "проверок МС" все Ок, а с точки зрения клиента - косяки.

==========
посмотрел что писали люди выше:
= согласен про base enum
= хорошо про перекрестные ссылки
= отлично про различие в написании полей
= замечательно про различие в MS SQL и Oracle версиях
= добавлю про работу с разными языками и метками... (например, в нумераторе хранится метка, метки могут хранится и в других местах. доступ к значениям меток организовать прямыми запросами очень проблематично)

===========
еще добавил
= при анализе конфигурационных и лицензионных ключей нужно разбирать не только наличие/отсутствие полей индексов, но также наличие отключенной таблицы в "середине" запроса. стандартный механизм худо-бедно с этой задачей справляется. Как с этим будет справляться прямой доступ к SQL - не знаю. В результате сам механизм анализа конфигурационных ключей и перестройки запроса супресложным получается. А следовательно сам по себе будет требовать отдельного и очень кропотливого тестирования.

===========
блин, еще добавил:

Цитата:

= если пользоваться recordset'ом, то прямой доступ к SQL теряет информацию о типах

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

[mazzy]

Цитата:

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

Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.

А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!

нафига НАМ (партнерам и клиентам) нужен какой-то левый инструмент, который Майкрософту (!) показывает "все ОК", хотя мы видим баг? Нафига нам нужен этот сферический конь в вакууме?

НАМ (партнерам и клиентам) нужно, чтобы правильно работал функционал, с которым МЫ работаем.
пусть пишут скрипты на Аксапте. либо пусть всю Аксапту переводят на C#.

По-моему, так.

[fed]

Цитата:

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

А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!

нафига НАМ (партнерам и клиентам) нужен какой-то левый инструмент, который Майкрософту (!) показывает "все ОК", хотя мы видим баг? Нафига нам нужен этот сферический конь в вакууме?

НАМ (партнерам и клиентам) нужно, чтобы правильно работал функционал, с которым МЫ работаем.
пусть пишут скрипты на Аксапте. либо пусть всю Аксапту переводят на C#.

По-моему, так.

Популизмом занимаешься.
Во первых - если при тестировании логистики вылезут ошибки .net bc, то логистика ведь тоже не оттестируется нифига, правда ? Могу предположить что в такой ситуации по полной программе вставят комманде .net bc, но в результате логистику зарелизят неоттестированой (потому что ждали починки .net bc вместо того чтобы тестировать).
Во вторых - то что средство тестирования и тестовая среда должны быть разделены - это некоторый очевидный постулат. Как я могу померить производительность системы, если средство измерения само съедает тики ? Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.

А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...

[mazzy]

Цитата:

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

Дык тогда надо ДВА набора скриптов просто - один для тестирование .net bc, второй для тестирования все остального.

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

Цитата:

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

У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария).

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

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

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

[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 - это верх изврата.