Прямое обращение к СУБД, минуя Axapta

[murad]

Есть стороннее приложение, которое должно работать с Axapta (+SQL Server).
Для ускорения работы запросов предлагается делать выборки напрямую
из SQL Servera, a запросы, модифицирующие данные, выполнять через логику Аксапты (через Com Connector)

В чем здесь могут быть подводные камни?
PS: при чтении данных нет необходимости проверять права на чтение. Считается, что приложение имеет максимальные права.

[George Nordic]

Ну, надо учесть DataAreaId.

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

[Gustav]

Если делать выборки напрямую, то я бы учёл следующее:

1. Присоединяюсь по DataAreaId к Георгию.
2. Поля дат - пустые с точки зрения Аксапты = 01.01.1990 с точки зрения SQL Server
3. Содержимое контейнерных полей будет недоступно
4. Енумы будут числами (для представления их "словами" можно сваять в БД дополнительный справочник всех енумов - я использую простенькую табличку AX_BASE_ENUMS из 4-х полей)

P/S:
5. В случае Oracle надо будет еще бороться с пустыми строками, выглядящими как Chr(2). Но раз речь об SQL Server, то неактуально.

P/S 23.01.07:
6. В случае Oracle я бы еще добавил, что нужно будет следить за регистром символов (особенно в условии WHERE)
7. Для любой СУБД нужно будет иметь в виду ситуации, связанные с использованием текстовых кодов (всякие id, accountnum и т.п.), выравненных по центру или по правому краю, когда в том же условии WHERE строку-фильтр нужно будет начинать слева некоторым количеством пробелов, которое не всегда очевидно (либо использовать славящийся своей неоптимальностью оператор LIKE '%<значение>%' ).

[KiselevSA]

А если пойти по обратному пути: запрашивать из Axapta данные для обновления из SQL, а само обновление производить через бизнес-логику. Одно дело, когда производится обновление полей в таблице, которые никак не завязаны на логику обработки, другое - обновлять данные, завязанные на разноску. По-моему, использование COM будет не быстрее связки методы Axapta -> данные в сторонней базе SQL

[murad]

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

[blokva]

Цитата:

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

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

+
А еще есть волшебная табличка InventDim например...и InventModule к примеру

[murad]

Цитата:

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

+
А еще есть волшебная табличка InventDim например...и InventModule к примеру

А что с ними не так?

[blokva]

Цитата:

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

А что с ними не так?

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

[e-Car]

Если приложение будет грузить SQL Server тяжёлыми запросами, если запросы будут написаны некорректно и будут "вешать" эксклюзивные блокировки, то последствия будут плохо предсказуемыми.
Вообще, "сажать" два транзакционных приложения на одну базу чревато взаимными блокировками (Axapta не догадывается, что она не одна...). Если же речь идет об аналитическом приложении, то его уж точно надо строить над хранилищем данных, куда по тем или иным правилам переносить информацию из транзакционной системы.

[George Nordic]

Кстати, а почему бы не использовать ReportServer? Он и данные потихоньку подкачивает, и основную базу не нагружает... Есть же у него какаие-то временные базы? Может, кто занимался этим вопросом?

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

[Maxim Gorbunov]

Цитата:

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

1. Присоединяюсь по DataAreaId к Георгию.
...
4. Енумы будут числами (для представления их "словами" можно сваять в БД дополнительный справочник всех енумов - я использую простенькую табличку AX_BASE_ENUMS из 4-х полей)

И зачем только разработчики Аксапты Business Views придумали?

Цитата:

Сообщение от George Nordic

Кстати, а почему бы не использовать ReportServer? Он и данные потихоньку подкачивает, и основную базу не нагружает... Есть же у него какаие-то временные базы? Может, кто занимался этим вопросом?

Reporting services использовать оччень неудобно (по крайней мере, пока). Есть проблемы с настройкой произвольных подитогов, форматированием отчетов. Не все поля корректно импортируются в Excel. Кроме того, мне не очень понятно, почему snapshot'ы отчетов можно делать только со значениями параметров по умолчанию (хотя здесь, возможно, я просто не уловил идею). Свои таблицы у сервера есть, и кэширование настроить можно. Другое дело, что это именно кэширование. То есть, обновление этих таблиц по расписанию (по ночам, например) мне настроить не удалось (в частности потому, что snapshot'ы работают только с параметрами по умолчанию). А вообще, Reporting services без Analysis services исплоьзовать, наверное, не стоит. Reporting services - это, все-таки, фронт-энд. Одна из его важных частей - report builder, с помощью которого пользователи могут построить свой отчет на лету. Вряд ли они при этом будут озабочены настройкой кэширования. А вот если данные, на основе которых отчет строится, будут лежать на analysis server, то администрирование всей системы будет проще.

[Gustav]

Цитата:

Сообщение от Maxim Gorbunov

И зачем только разработчики Аксапты Business Views придумали?

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

То, что придумали - молодцы, конечно. А вот если бы как-то еще и донесли до широкой общественности, то цены бы им не было (в русском мануале "Администрирование" я об этом ничего не нашёл).

Я, как бы это сказать... "вхож" в два внедрения Аксапты 3.0, выполненными разными внедренцами. В одном из них эта фича присутствует. По меню это: "Администрирование - Настройки - Бизнес-анализ - Бизнес-представления - Перечислимые тексты". Причем, нажатие на кнопку "Проверка перечислимых текстов" и дальнейшее подтверждение языка "Ru" не имеет никакого эффекта - ничего не происходит. Тем не менее, уже вижу, хоть и пустые, но таблицы BASEnumTable и BASEnumValueLine, а также классы BASEnumDoAll и BASEnumEngine. Во втором внедрении такого пункта меню нет, не созданы таблицы в базе (хотя описание в репозитарии, конечно, присутствует). Видимо, вторые внедренцы решили, что "оно нам такое не надо" и фичу эту соответствующим ключом не открыли.

[AraraT®]

Присоединяюсь к e-Car, у нас тоже есть сторонняя программа, которая строит разного вида отчета (ну неумели мы на тот момент программировать на X++), так вот, если Акса блокирует таблицу, то программа не может выбрать данные. Или же когда идет обновление приложения, АОС остановлен, а база доступна, что тоже создает некоторые осложнения.

[murad]

И ещё такой вопрос: если, например, для полнотекстового поиска повесить доп. индексы на таблицы Аксапты. То не будет ли аксапта удалять эти индексы при синхронизации или компиляции? И существует ли удобный механизм делать такой поиск средствами Аксапты, не считая варианта с ручным прописыванием запроса "INNER JOIN ... CONTAINSTABLE" ?

[Gustav]

Цитата:

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

...если, например, для полнотекстового поиска повесить доп. индексы на таблицы Аксапты.
То не будет ли аксапта удалять эти индексы при синхронизации...?

Будет ругаться, будет удалять - если индексы созданы средствами СУБД вне Аксапты.
Выход - создайте доп.индексы в самой Аксапте (в AOTе)


P.S.Forward

Цитата:

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

А можно ли создать полнотекстовый индекс средствами Аксапты, а не SQL Servera?
Насколько я знаю - нет.
(Axapta 3.0 SP3)

я не в курсе, врать не буду

[murad]

Цитата:

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

Будет ругаться, будет удалять - если индексы созданы средствами СУБД вне Аксапты.
Выход - создайте доп.индексы в самой Аксапте (в AOTе)

А можно ли создать полнотекстовый индекс средствами Аксапты, а не SQL Servera?
Насколько я знаю - нет.
(Axapta 3.0 SP3)

[KiselevSA]

Цитата:

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

И ещё такой вопрос: если, например, для полнотекстового поиска повесить доп. индексы на таблицы Аксапты. То не будет ли аксапта удалять эти индексы при синхронизации или компиляции? И существует ли удобный механизм делать такой поиск средствами Аксапты, не считая варианта с ручным прописыванием запроса "INNER JOIN ... CONTAINSTABLE" ?

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

По поводу запросов - почему бы не присмотреться к executeQuery с передачей запроса к SQL "открытым" текстом?

[sergeypp]

Стоит учесть что эта база не является рабочей.. В ней создаются заказы и только.. Может быть заказ будет помечаться как обработанный, но это можно сделать избежав блокировок необходимых для выборки страниц.. Все бизнес процессы будут приосходить в рабочей базе, куда будут передаваться обработанные (или подтвержденные ) заказы. Одновременно будет работать ну максимум человек 5.. Я не думаю.. что они будут тормозить систему.. Если блокировки и будут создаваться, то можно использовать схему запроса с NOLOCK. Я не думаю, что для вывода информации из текущей базы нужны актуальные данные.. Если даже в дальнейшем там и появятся какие то бизнес процессы, они не будут оказывать большого влияния на быстродействие системы.. Что касается аналитик, то аналитики будут только по складу и ячейке, причем на каждом складе будет максимум 1 ячейка.. в Течении дня будет создаваться максимум 100 строк заказов.. Так что размер INVENTDIM будет не существенен...
2 e-Car.. а можно уточнить про "(Axapta не догадывается, что она не одна...)" а что?? в аксапте есть система управления блокировками??? мне не понятен смысл этого выражения.. поясните, будьте так добры..

[e-Car]

С одной базой работает 2 приложения. Работает много пользователей. Они периодически жалуются на какие-то ошибки, которые то возникают, то нет. В одних и тех же ситуациях. В тестовых условиях ошибки не воспроизводятся. Что будете делать? Включать трассировку SQL на всё время работы, на все выполняемые с базой операции? Опрашивать кто что делал с 10 до 11? В каком из приложении и в каком именно месте искать ошибку? А если ошибки нет, а просто одно приложение не учитывает, что другое приложение (про поведение которого это первое ничего не знает, поскольку создавалось отдельно, как самостоятельное приложение) тоже может изменять данные, блокировать (не дай Бог эксклюзивно) таблицу на ма-а-а-аленький промежуток времени? Вы, я так понимаю, ошибок в коде не допускаете? Так сказать "сделай правильно с первого раза". Тогда я Вас обрадую - в Аксапте ошибок хоть отбавляй, особенно если в ней меняли хоть что-то в качестве доработки.
P.S. Если база не рабочая, то можете делать с ней что хотите. Хоть десять приложений "навешать". Мои соображения относятся только к работающим системам. В начальном вопросе не было ничего про "Стоит учесть что эта база не является рабочей.. В ней создаются заказы и только.."

[sergeypp]

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

Цитата:

Сообщение от e-Car

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

Т.е. с ваших слов ситуация когда, один пользователь в Аксапте блокирует другого пользователя коренным образом отличается от ситуации, когда одно приложение блокирует другое.. Я же не вижу принципиальных различий. Блокировки обрабатываются на уровне скуля. И нет разницы кто и как заблокировал приложение. Разве не так??