|
17.09.2010, 10:38 | #1 |
Участник
|
Выборка данных через AOS vs SQL Server
У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server (Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария). Я что-то не могу вспомнить недостатков прямого похода через SQL, кроме нижеприведенных. Помню, что массу раз обсуждалось, но не нашел ничего интересного. Добавьте кто что может Недостатки SQL: - Не учитывает настроек безопасности (особенно RLS) - Проблемы с генерацией RecId при необходимости вставки данных Недостатки AOS: - Медленнее |
|
17.09.2010, 10:47 | #2 |
MCT
|
Плюс к тому же надо всегда протягивать идентификатор компании.
Ну и не видно кто таки создал запись. Но скорость.. в третьей версии на порядки отличалась.
__________________
Axapta book for developer |
|
17.09.2010, 10:52 | #3 |
Участник
|
Минус AOS - ограниченный синтаксис запросов, что зачастую и ведет к уменьшению скорости выполнения.
Насчет RLS - если запросы выполняются через select, то о его включении надо заботиться дополнительно. Что не всегда делается. Опять же - для валидации зачем нужны настройки доступа?
__________________
Axapta v.3.0 sp5 kr2 |
|
17.09.2010, 10:55 | #4 |
Участник
|
Ну, собственно, прямые SQL-запросы пишутся именно по той причине, что выборка через AOS слишком медленно. А из недостатков, еще добавлю
- Не все настройки физически хранятся в таблицах на SQL-сервере. Часть настроек находится только на AOS. Например, Base Enum |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
17.09.2010, 11:02 | #5 |
MCT
|
тут еще такой неявно-замалчиваемый момент есть, это архитектура модификаций.
Если связи построены криво, и нужен left outer join, то опять надо в базу лезть, что б данные получить.
__________________
Axapta book for developer |
|
17.09.2010, 11:02 | #6 |
----------------
|
через SQL
- не забыть идентификаторы компании, особенно для общих таблиц и виртуальных компаний - привязка к текущей модели данных, добавление/удаление/отключение столбцов и запрос надо править. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
17.09.2010, 12:01 | #7 |
Administrator
|
Цитата:
Еще момент. Названия таблиц / полей в АОТ и в БД - вообще говоря могут отличаться (если длина названия больше 30 символов). А что значит "данные выбираются для валидации"? Типа закрыли склад и сделали выборку - все ли пересчиталось?
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
17.09.2010, 11:05 | #8 |
Участник
|
Цитата:
Сообщение от kashperuk
У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server (Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария). Я что-то не могу вспомнить недостатков прямого похода через SQL, кроме нижеприведенных. Помню, что массу раз обсуждалось, но не нашел ничего интересного. Добавьте кто что может Недостатки SQL: - Не учитывает настроек безопасности (особенно RLS) - Проблемы с генерацией RecId при необходимости вставки данных Недостатки AOS: - Медленнее Или разработчики в Майкрософт на такие мелочи уже давно не обращают внимания ? |
|
17.09.2010, 11:27 | #9 |
Участник
|
no comments.
|
|
17.09.2010, 11:38 | #10 |
Участник
|
Неужели его все таки похоронили в последних версиях Аксапты ?
|
|
17.09.2010, 11:47 | #11 |
Участник
|
Почему же, 2009sp1 + 10g вполне мирно сосуществуют.
В директ запросах надо помнить про то, что CI требует nls_lower(), а правое выравнивание некоторых типов соответственно substr(). |
|
17.09.2010, 11:55 | #12 |
Участник
|
еще при прямом запросе перекрестных ссылок использования таблиц не будет
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
17.09.2010, 12:18 | #13 |
Участник
|
Ну, к примеру, создали заказ на продажу, обработали накладную, и хотим посмотреть, как выглядят складские проводки для строки заказа.
|
|
17.09.2010, 13:06 | #14 |
Moderator
|
Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.
Ведь для того тестовые скрипты и написали на C# чтобы не создавать проблем "квантового порядка", когда тестовые скрипты на X++ сами изменяют наблюдаемую среду. А получается что вы сначала все тестовые скрипты написали на C#, а потом сами же свою идею ломаете.... |
|
17.09.2010, 14:39 | #15 |
Участник
|
Цитата:
Сообщение от fed
Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.
пусть натыкаются и исправляют глюки в BC. пусть натыкаются и исправляют глюки в методах и классах доступа к данным пусть натыкаются и исправляют проблемы с производительностью!!! нафига НАМ (партнерам и клиентам) нужен какой-то левый инструмент, который Майкрософту (!) показывает "все ОК", хотя мы видим баг? Нафига нам нужен этот сферический конь в вакууме? НАМ (партнерам и клиентам) нужно, чтобы правильно работал функционал, с которым МЫ работаем. пусть пишут скрипты на Аксапте. либо пусть всю Аксапту переводят на C#. По-моему, так. |
|
|
За это сообщение автора поблагодарили: lev (6). |
17.09.2010, 14:43 | #16 |
Moderator
|
Цитата:
Сообщение от 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 | #17 |
Участник
|
Цитата:
Цитата:
В общем, пусть идут в пень со своими заморочками насчет производительности. Если есть проблемы с производительностью, то не надо нам подсовывать workaround через прямые запросы к SQL. Проблемы с производительностью надо выявлять. А не заметать под коврик прямыми запросами в SQL. ТОЧКА. Проблемы с производительностью надо править в ядре и в стандартном функционале теми же средствами, которые юзают клиенты и партнеры. ТОЧКА. |
|
17.09.2010, 15:09 | #18 |
Участник
|
Как скажешь.
Я думаю, что высказал свое личное мнение и свою личную озабоченность происходящим. Цитата:
Сообщение от fed
Во первых - если при тестировании логистики вылезут ошибки .net bc, то логистика ведь тоже не оттестируется нифига, правда ? Могу предположить что в такой ситуации по полной программе вставят комманде .net bc, но в результате логистику зарелизят неоттестированой (потому что ждали починки .net bc вместо того чтобы тестировать).
Меня сильно волнует, что в логистике вылезают ошибки. Если честно, то лично меня не устраивает механизм тестирования, который сильно отличается от стандартного механизма. Потому что сам механизм тестирования может содержать баги. Как и ядро может содержать баги. Лично мне абсолютно пофигу где ошибка - в логистике, в ядре в алгоритме тестирования. Главное что она есть. И меня клиент заставит ее исправлять. Лично я хочу видеть максимально похожий на стандартный механизм тестирования. Только так я могу быть уверен, что разработчик получает при тестировании те же ошибки, что и я. Только так я могу быть верить разработчикам (хоть с какой-то степенью). Цитата:
Во-вторых, во ходе замеров производительности никогда не оперируют абсолютными числами. Оперируют некими попугаями. операция сложения - столько то попугаев. операция деления - столько то попугаев. операция доступа к записив базе - столько то попугаев. а вот этот тривиальный алгоритм выборки суммы вдруг отжирает в несколько сот попугаев больше. значит надо разбираться с алгоритмом. Где-то тут была тема со сравнением производительности арифметических операций в ax3, ax4, ax2009. Хоть там и говорилось про время. Но важны были относительные величины, а не абсолютные. Цитата:
Сообщение от fed
Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.
Во-вторых, это не повод использовать для валидации какие-то левые механизмы (см. первое сообщение в этой ветке ) В-третьих, тут также важны относительные значения. Вот этот алгоритм - столько то канареек, а вот этот в сотни раз больше. Ну, не хочешь же ты сказать, что средство тестирования жрет память неконтролируемо. Ни за что не поверю. Цитата:
Сообщение от fed
А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...
Но обсуждение "управляемости проектом" - точно оффтопик в этой ветке. |
|
17.09.2010, 13:05 | #19 |
Участник
|
Для прямого запроса через ADO/ODBC нужно на клиенте иметь настроенные драйвера и права на подключение к серверу.
Или запрос делаете на AOSе ? |
|
17.09.2010, 14:35 | #20 |
Участник
|
Цитата:
Сообщение от kashperuk
Выборка через АОС или выборка напрямую из SQL Server
(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария). Я что-то не могу вспомнить недостатков прямого похода через SQL, кроме нижеприведенных. Помню, что массу раз обсуждалось, но не нашел ничего интересного. Добавьте кто что может Недостатки SQL: - Не учитывает настроек безопасности (особенно RLS) - Проблемы с генерацией RecId при необходимости вставки данных Недостатки AOS: - Медленнее = не учитывается кэширование, которое выполняет Аксапта. (что очень плохо) = не учитывается метод 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 теряет информацию о типах
Для тестирования важно, что теряется свойство validation, указанное в relation. кроме relation в типах также теряется relation, указанный в таблицах Последний раз редактировалось mazzy; 17.09.2010 в 15:46. Причина: добавил 3 |
|
|
За это сообщение автора поблагодарили: sukhanchik (8), Logger (5), zhan (2). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|