SAP или 1С?

[Recoilme]

Цитата:

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

Доброе время суток .

а вот то , что касается огромной производительности и количества пользователей – непонятно. Отсюда следует вопрос – за счет каких это секретных СУБД и ноу-хау появляется это конкурентное преимущество. Хотелось бы услышать ответ SAP. ( К 1С отношения не имею ) .[/size][/font]

Буду благодарен всем кто выскажется по этому поводу.

Конечно саперы лучше скажут за счет каких именно, но навскидку:
http://www.sapbasis.ru/articles/abapperfrules/
http://www.sapbasis.ru/articles/opensqlhints/
Возможности по оптимизации запросов - шире на порядок. Если Аксапта оптимизирует сама и зачастую ДЕоптимизируют - в САП можно этим играть и довольно тонко, вплоть до разные хинты для разных субд

[mifi]

Цитата:

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

Конечно саперы лучше скажут за счет каких именно, но навскидку:
http://www.sapbasis.ru/articles/abapperfrules/
http://www.sapbasis.ru/articles/opensqlhints/
Возможности по оптимизации запросов - шире на порядок. Если Аксапта оптимизирует сама и зачастую ДЕоптимизируют - в САП можно этим играть и довольно тонко, вплоть до разные хинты для разных субд

Уважаемы Recoilme.
Прочитал обе статьи в ссылках, не нашел ничего такого, что не нельзя было бы настроить в X++. Первая статья - общие советы, по сути, не привязанные к базе данных и среде разработки, количество хинтов, описанных во второй - не впечатляет, в X++ их побольше будет. Не можете уточнить, в чем возможности по оптимизиции шире на порядок - в том, что нужно указывать СУБД для одинакового набора хинтов (по крайней мере, для MS SQL Server и Oracle я никаких различий в хинтах не нашел)?

[Recoilme]

Цитата:

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

Уважаемы Recoilme.
Прочитал обе статьи в ссылках, не нашел ничего такого, что не нельзя было бы настроить в X++. Первая статья - общие советы, по сути, не привязанные к базе данных и среде разработки, количество хинтов, описанных во второй - не впечатляет, в X++ их побольше будет. Не можете уточнить, в чем возможности по оптимизиции шире на порядок - в том, что нужно указывать СУБД для одинакового набора хинтов (по крайней мере, для MS SQL Server и Oracle я никаких различий в хинтах не нашел)?

Попробую обосновать (честно говоря сужу по описанию САПа, как там на практике - не знаю).
1. Например, столкнулся с ситуацией описаной здесь:
Управление опциями SQL запроса
когда аксапта ко ВСЕМ запросам добавляет неотключаемый хинт оптионфаст приводящий к полному ауту в отдельных случаях.

Насколько я понял в САПЕ это регулирует разработчик

Цитата:

Вместо того чтобы явно указывать индекс, часто достаточно просто «намекнуть» оптимизатору на необходимость его использования. Выбор подходящего индекса оптимизатор сделает сам:

SELECT * FROM RESB
WHERE MATNR = '200-100' AND WERKS = '1100'
%_HINTS ORACLE 'FIRST_ROWS'.

2. &REPARSE&
Сталкивался с ситуациями когда по непонятным причинам в одном и том же запросе то строился правильный план - то не строился, подозреваю что этот хинт мне бы помог так как юзался старый план.
3. SAP_FORCE_CLOSE_CURSOR, OPTION FAE_UNION и OPTION FAE_JOIN
точно не знаю, но возможно тоже могли бы пригодится.

Огромная просьба, расскажите если не сложно, как это можно на х++ реализовать,

Минусы (на мой взгляд, если не так - просвятите плз):

4. Честно говоря я думал в САПе сцылочная целкостность, тригеры хранимки на уровне БД, а теперь такое ощущение что нет? пора разочароваться?

5. Вроде как в дждиэдвардс только так(4), получается , из известных?

6. Инфо-предприятие - рулез форева, поскольку выходит только в нем?!?!? я могу написать ПЛАН(ывалыдвллвыа) и непариться вообще?

ой, не заметил:

Цитата:

- в том, что нужно указывать СУБД для одинакового набора хинтов

Думаю это плюс. В разных СУБД разный оптимизатор, где то хинты навредят, где то помогут, в общем случае

[mifi]

Цитата:

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

Попробую обосновать (честно говоря сужу по описанию САПа, как там на практике - не знаю).
1. Например, столкнулся с ситуацией описаной здесь:
Управление опциями SQL запроса
когда аксапта ко ВСЕМ запросам добавляет неотключаемый хинт оптионфаст приводящий к полному ауту в отдельных случаях.

Насколько я понял в САПЕ это регулирует разработчик

2. &REPARSE&
Сталкивался с ситуациями когда по непонятным причинам в одном и том же запросе то строился правильный план - то не строился, подозреваю что этот хинт мне бы помог так как юзался старый план.
3. SAP_FORCE_CLOSE_CURSOR, OPTION FAE_UNION и OPTION FAE_JOIN
точно не знаю, но возможно тоже могли бы пригодится.

Огромная просьба, расскажите если не сложно, как это можно на х++ реализовать,

Минусы (на мой взгляд, если не так - просвятите плз):

4. Честно говоря я думал в САПе сцылочная целкостность, тригеры хранимки на уровне БД, а теперь такое ощущение что нет? пора разочароваться?

5. Вроде как в дждиэдвардс только так(4), получается , из известных?

6. Инфо-предприятие - рулез форева, поскольку выходит только в нем?!?!? я могу написать ПЛАН(ывалыдвллвыа) и непариться вообще?

ой, не заметил:

Думаю это плюс. В разных СУБД разный оптимизатор, где то хинты навредят, где то помогут, в общем случае

Давайте по пунктам.
1. Эта функциональность Аксапты описывается как один из основных принципов оптимизации в вашей ссылке №1 (Выбирайте только необходимые записи) По поводу намеку оптимизатору - я не понял, почему вы называете это "намеком", из текста статьи следует, что это именно указание использовать данный индекс (вариант того, что такого индекса нет, не рассматриваем), т.е. поведение аналогичное index hint в X++.
2. Практически подобного же поведения можно добиться, используя ключевое слово forceLiterals - тогда, чтобы оптимизатор БД взял старый план, запрос должен быть тем же самым с точности до значений полей.
3. IMHO, детали реализации ABAP.

[asd_]

Можно подвести итог - если приложение будет использовать ХП и другие особенности конкретной СУБД ,то мы получим значительно более производительное приложение чем динамический SQL преобразованный с языка АВАР т.е. SAP в данном случае проигрывает. Следовательно любое приложение, в том числе и 1С будет работать также (если не лучше) чем SAP. Поэтому все утверждения об огромных возможностях просто вымысел.