Native SQL в ABAP в большей степени предназначен для доступа к не родным БД
нут так и в 1С при желании можно зацепиться к любой БД через какой нибудь COM коннектор

А потом повеситься самому!



Точно, к усыновленным! Предлагаю переименовать Native SQL в Adopted SQL!

Кстати, очень интересно проанализировать отношение к языку SQL в сапе и 1с. Например, стремясь к одной и той же цели - повышению производительности сап и 1ска дают практически диаметрально противоположные советы по оптимизации запросов.

Подход 1с, как я его вижу:



Собственно меня и на курсах так учили - пишем огроооооомный sql-запрос который собирает все данные какие надо, все что не надо выкидывает, что надо рассчитывает, потом десятью операторами выводим это в красивый отчет.

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

В итоге смысл такой: в подходе 1с более интенсивно используется сама концепция реляционных баз данных - СУБД внутренними механизмами оптимизирует запрос, используя реляционную алгебру в целом на получении одних и тех же данных тратится меньше вычислительных ресурсов компьютера.
в подходе сапа - приложение которое выполняется на сервере приложений старается создать минимальную нагрузку на сервер БД, но за счет большего расходования своих ресурсов.

Теперь если попробовать масштабировать какую-нибудь сферическую задачу в 10, 100 и т.п. раз. Увеличивается количество пользователей, увеличивается количество транзакций, обработок. 1с-ке для увеличения производительности в большей степени необходимо увеличивать производительность сервера БД, сервер приложений испытывает меньшую нагрузку. В сапе наоборот - большую нагрузку испытывает сервер приложений, а нагрузка на сервер бд растет не так быстро.
Получается что в какой-то определенный момент или сервер приложений или сервер БД становятся причиной тормозов. Но в итоге масштабировать сервер приложений гораздо проще - нужно просто купить еще 1 комп и настроить его на работу в соответствующем ландшафте, а чтобы увеличить производительность сервера БД (по крайней мере в сапе) базису придется неплохо потрудиться.

Правильно учили, потому что речь идет об ОТЧЕТЕ. При его реализации надо помнить о проблеме повторного чтения. Разбивая запросы на отдельные фрагменты можно получить некорректный отчет. В SAP технология одного запроса не всегда работает по причине ограниченности open SQL. Поэтому, чтобы не перегружать БД, как вы правильно сказали, используют отдельные запросы, даже при построении ОТЧЕТОВ.

Если же речь идет не об ОТЧЕТЕ, а о транзакционном функционале, то в любом трехуровневом приложении всегда рекомендуется использовать простые отдельные DML-команды (включая и SELECT-ы), а всю логику выполнять на стороне сервера приложений. Я не знаю как устроен 1С, но если он поддерживает возможность масштабирования посредством увеличения количества серверов приложений, то для него такая концепция построения запросов тоже оправдана

Так что разница в подходах к построению приложений в SAP и 1С скорее всего нет.

Масштабирование посредством серверов приложений имеет смысл до определенного момента. Нет линейной зависимости, слишком много факторов. Не получится добиться масштабированности в 10 раз (не говоря уже о 100) только заменой 1-го сервера приложений на 10, потому что узкое место обращения к БД останется. Например, если загружен сервер приложений на 100%, а база данных на 30%, то увеличив количество серверов приложений до 2-х, можно получить новое соотношение нагрузки, например, 80% на 80%. И дальнейшее увеличение серверов приложений никакой пользы не принесет.

Очень забавно!
Такой подход был единственно возможным в версии 1С 7.7, ведь в ней не было даже возможности выборки более-менее сложного соединения нескольких таблиц. Поэтому все отчеты строились именно так, как Вы написали. Простые выборки загружались в таблицы в памяти клиента и сопоставлялись на языке 1С. Это все хорошо, но скорость построения таких отчетов на порядки! медленнее. Это и понятно - разве может высокоуровневый язык-интерпретатор сравниться быстродействием с оптимизированной выборкой СУБД ???
В 1С 8 разработчику предоставляется выбор - делай, как тебе удобнее. Существует масса примеров отчетов в 1С с применением как единого запроса, так и нескольких последовательных запросов.

Еще один немаловажный момент. В 1С можно управлять, где будет выполняться код обработки - на сервере приложений или на клиенте. По умолчанию, кстати, весь прикладной код выполняется на клиенте. Следовательно, нагрузка сервера приложений в таком режиме не очень высокая. Если грамотно разнести точки выполнения кода, то можно здорово оптимизировать производительность системы в целом.

А вообще по поводу отчетов нам нужно не забывать, что в крупных предприятиях отчеты, как правило, выносят на отдельный OLAP-сервер.
В 1С иногда просто выделяют отдельную зеркальную копию рабочей базы специально для задач построения отчетов. Репликация между основной и зеркальной копиями выполняется встроенными в 1С средствами построения распределенных БД.

фейспалм

Не поверите... у SAP для этого целый модуль есть

Вот только отлаживать такой "огроооооомный sql-запрос" иногда очень не просто

Да, это правда, но зато потом быстро работает.
При этом в 1С язык запросов более приятен для восприятия по сравнению с SQL. Вот простой пример запроса, который выдает весь товарный каталог с текущим остатком:

ВЫБРАТЬ
Номенклатура.Ссылка,
Номенклатура.Код,
Номенклатура.Артикул,
Номенклатура.ТорговаяМарка.Наименование,
ОстаткиТоваров.КоличествоОстаток
ИЗ
Справочник.Номенклатура КАК Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ
РегистрНакопления.ОстаткиТоваров.Остатки(&ДатаОстатков) КАК ОстаткиТоваров
ПО
Номенклатура.Ссылка = ОстаткиТоваров.Номенклатура

Как видите, удобочитаемость таких запросов достаточно высокая.

Это же сколько кнопок нажать надо? В SAP вся эта строка заняла бы 4 символа.

Извиняюсь, не 4 ,в большинстве случаев 5.

2 ilsik

Зрите в корень

Объектная модель запросов. Не знаю уж насколько эффективно, но довольно прикольно.

murmur, это в каком месте оно объектное? Как был декларативный запрос, так и остался. Синтаксис сменили, да