AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.09.2010, 10:38   #1  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,360 / 2083 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
Выборка данных через AOS vs SQL Server
У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

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

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

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

Недостатки AOS:
- Медленнее
Старый 17.09.2010, 10:47   #2  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,627 / 628 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Плюс к тому же надо всегда протягивать идентификатор компании.
Ну и не видно кто таки создал запись.
Но скорость.. в третьей версии на порядки отличалась.
__________________
Axapta book for developer
Старый 17.09.2010, 10:52   #3  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2468 (88) +++++++++
Регистрация: 20.08.2005
Минус AOS - ограниченный синтаксис запросов, что зачастую и ведет к уменьшению скорости выполнения.

Насчет RLS - если запросы выполняются через select, то о его включении надо заботиться дополнительно. Что не всегда делается.
Опять же - для валидации зачем нужны настройки доступа?
__________________
Axapta v.3.0 sp5 kr2
Старый 17.09.2010, 10:55   #4  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,576 / 1108 (40) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Ну, собственно, прямые SQL-запросы пишутся именно по той причине, что выборка через AOS слишком медленно. А из недостатков, еще добавлю

- Не все настройки физически хранятся в таблицах на SQL-сервере. Часть настроек находится только на AOS. Например, Base Enum
За это сообщение автора поблагодарили: mazzy (2).
Старый 17.09.2010, 11:02   #5  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,627 / 628 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
тут еще такой неявно-замалчиваемый момент есть, это архитектура модификаций.
Если связи построены криво, и нужен left outer join, то опять надо в базу лезть, что б данные получить.
__________________
Axapta book for developer
Старый 17.09.2010, 11:02   #6  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 851 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
через SQL
- не забыть идентификаторы компании, особенно для общих таблиц и виртуальных компаний
- привязка к текущей модели данных, добавление/удаление/отключение столбцов и запрос надо править.
За это сообщение автора поблагодарили: mazzy (2).
Старый 17.09.2010, 11:05   #7  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,644 / 2570 (93) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от kashperuk Посмотреть сообщение
У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

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

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

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

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

Или разработчики в Майкрософт на такие мелочи уже давно не обращают внимания ?
Старый 17.09.2010, 11:27   #8  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,360 / 2083 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
Цитата:
Сообщение от Logger Посмотреть сообщение
Или разработчики в Майкрософт на такие мелочи уже давно не обращают внимания ?
no comments.
Старый 17.09.2010, 11:38   #9  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,644 / 2570 (93) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Неужели его все таки похоронили в последних версиях Аксапты ?
Старый 17.09.2010, 11:47   #10  
AK-76 is offline
AK-76
Участник
 
60 / 19 (1) ++
Регистрация: 22.07.2003
Адрес: Barcelona, Spain
Почему же, 2009sp1 + 10g вполне мирно сосуществуют.

В директ запросах надо помнить про то, что CI требует nls_lower(), а правое выравнивание некоторых типов соответственно substr().
Старый 17.09.2010, 11:55   #11  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,509 / 344 (15) ++++++
Регистрация: 23.03.2006
еще при прямом запросе перекрестных ссылок использования таблиц не будет
За это сообщение автора поблагодарили: mazzy (2).
Старый 17.09.2010, 12:01   #12  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,103 / 3185 (113) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Wamr Посмотреть сообщение
через SQL
- привязка к текущей модели данных, добавление/удаление/отключение столбцов и запрос надо править.
Кстати - да - права доступа / конфигурационные ключи / лицензии - вся эта информация есть только в АХ.
Еще момент. Названия таблиц / полей в АОТ и в БД - вообще говоря могут отличаться (если длина названия больше 30 символов).

А что значит "данные выбираются для валидации"? Типа закрыли склад и сделали выборку - все ли пересчиталось?
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: mazzy (2).
Старый 17.09.2010, 12:18   #13  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,360 / 2083 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
Ну, к примеру, создали заказ на продажу, обработали накладную, и хотим посмотреть, как выглядят складские проводки для строки заказа.
Старый 17.09.2010, 13:05   #14  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Для прямого запроса через ADO/ODBC нужно на клиенте иметь настроенные драйвера и права на подключение к серверу.
Или запрос делаете на AOSе ?
Старый 17.09.2010, 13:06   #15  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,725 / 5418 (186) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.
Ведь для того тестовые скрипты и написали на C# чтобы не создавать проблем "квантового порядка", когда тестовые скрипты на X++ сами изменяют наблюдаемую среду. А получается что вы сначала все тестовые скрипты написали на C#, а потом сами же свою идею ломаете....
Старый 17.09.2010, 14:35   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,463 / 4337 (203) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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, указанный в таблицах
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 17.09.2010 в 15:46. Причина: добавил 3
За это сообщение автора поблагодарили: sukhanchik (8), Logger (5), zhan (2).
Старый 17.09.2010, 14:39   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,463 / 4337 (203) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.
А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!

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

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

По-моему, так.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: lev (6).
Старый 17.09.2010, 14:43   #18  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,725 / 5418 (186) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mazzy Посмотреть сообщение
А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!

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

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

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

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

Последний раз редактировалось fed; 17.09.2010 в 14:56.
Старый 17.09.2010, 14:54   #19  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,463 / 4337 (203) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Дык тогда надо ДВА набора скриптов просто - один для тестирование .net bc, второй для тестирования все остального.
возвращаемся к первоисточнику
Цитата:
Сообщение от kashperuk Посмотреть сообщение
У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

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

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

Проблемы с производительностью надо выявлять. А не заметать под коврик прямыми запросами в SQL. ТОЧКА.
Проблемы с производительностью надо править в ядре и в стандартном функционале теми же средствами, которые юзают клиенты и партнеры. ТОЧКА.
__________________
полезное на axForum, github, vk, coub.
Старый 17.09.2010, 15:02   #20  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,725 / 5418 (186) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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 - это верх изврата.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
SQL Server 2005, 2008: Создание недостающих индексов Poleax DAX: Прочие вопросы 6 05.06.2010 01:28
axperf: Important SQL Server Change! - Parameter Sniffing and Query Plan Caching Blog bot DAX Blogs 3 24.05.2010 02:53
Dynamics AX Sustained Engineering: SQL Server 2005 sp3 & SQL Server 2008 with Dynamics AX Blog bot DAX Blogs 0 12.02.2009 06:08
Arijit Basu: Microsoft SQL Server Reporting Services Integration Blog bot DAX Blogs 0 20.07.2007 11:50
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:45.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.