Нет, Артем, Вы не правы. Изменился именно подход к построению запросов. Вы видели запросы в версии 1С 7.7 ? Это была в чистом виде декларативная форма описания результата, еще и в очень корявом исполнении! Честно Вам скажу, я более 3-х лет работал в 1С 7.7, но так и не смог освоить ее язык запросов.

А в 1С 8 явно виден качественный рывок в сторону прямой трансляции в SQL. Это же заметно невооруженным глазом!
И я буквально за 1 год освоил язык запросов 1С до такой степени, что могу по нему читать лекции!

Вот вам тест-задача. Оцените, как в САПе решить задачу расчета среднесуточного объема остатка товара на складе. Меня в этой задаче интересует, прежде всего, сам принцип расчета СРЕДНЕСУТОЧНОГО показателя.
Скажу сразу, что в 1С такая задача решается довольно просто одним запросом без временных таблиц.

Подход не изменился. Он с 80х годов прошлого века не менялся. Добавилось выразительных средств языка.

Что касается теста:
1. В 1С проще структура БД
2. В SAP, в силу мультиплатформенности системы, очень ограничен внутренний диалект SQL
3. Смысла гнаться за флагом "все в одном запросе" не вижу совершенно. Часто это порочный путь.

Согласен с тем, что реляционный принцип организации БД остался неизменным. На таком уровне можно вообще сказать, что все системы учета, которые используют реляционные БД, одинаковые. Это все знают, и можно было бы об этом даже не упоминать.
Я же говорю о новых технических средствах решения прикладных задач и, в частности, об организации запросов к БД.

И все-таки скажите, как в САПе рассчитать среднесуточный остаток товаров за определенный период, например, за прошлый год?
Неужели для этого придется писать функцию, которая в цикле получит остаток на конец каждого дня в году, и потом усреднит 365 полученных значений?
А что, если потребуется рассчитать среднесуточный остаток за 5 лет?

Prokop, я говорю не о реляционной модели, а о семантике языков доступа к данным в этой модели. Которая не претерпела никаких изменений за последние 30 лет.

По поводу среднесуточного остатка - скорее всего да, придется анализировать движения материалов.
Но я не вижу практической ценности в такой задаче. О чем нам скажет этот показатель?

О том как просто его получить. О чём же ещё??

а так - чисто поинтересоваться - en-версия макроязыка есть? как насчёт "в мировом масштабе, василь иваныч"?

Именно так. На 5 лет запланирую Job, который мне через полчасика вернет результат

Пример не показателен по одной простой причине. Для подобных отчетов есть модуль BI/BW где строится модель хранения данных и преобразования данных таким образом, что остаток товара получается в хоть а разрезе дней, хоть в разрезе видов товаров, хоть в разрезе полок для складирования, хоть по поставщикам. Отчеты на основе такой модели получаются с очень приличной производительностью.

А вот сколько будет работать ваша выборка на продуктивной базе (блокируя таблицы и загружая ЦП на 100%, агрегируя на уровне БД) если, например, в день делается около 10000 операций проводки материалов? Поэтому согласен на 100% с пунктом 3 Артёма.

Разведка доносила что есть. Но писать на ней строжайше запрещено регламентами разработок.
За правдивость разведчика не ручаюсь.


Сразу с козырей не интересно.
Хотя что там у 1С на фронтах OLAP я бы послушал от знающих людей с удовольствием.

Да, есть. Это было и в версии 7.7.
И никто не запрещает писать на английской версии. Просто это не очень удобно, когда есть выбор писать на русском. Можно нормально называть переменные, текст программы понятнее и т.д.

Хотя это все дело привычки. 1С просто предоставляет выбор.

Не очень долго. Точно не полчаса, даже при таком большом количестве данных. Ведь для этого будет использована специальная предварительно рассчитанная таблица итогов (агрегатов) для регистра остатков товаров. Более подробно структуру этой таблицы я сейчас описать не смогу, скажу только, что в этой таблице уже хранятся остатки на начало каждого месяца и агрегированные обороты за каждый месяц в разрезе каждого измерения.

Вот пример текста запроса, которым можно получить среднесуточный остаток

ВЫБРАТЬ

Данные.Остаток / РАЗНОСТЬДАТ(&НачПериода, ДОБАВИТЬКДАТЕ(&КонПериода, СЕКУНДА, 1), ДЕНЬ) КАК Сумма
ИЗ
(ВЫБРАТЬ
СУММА(ВЗ.Остаток) КАК Остаток
ИЗ
(ВЫБРАТЬ
Данные1.Период,
ВЫБОР КОГДА НЕ (МИНИМУМ(Данные2.Период) ЕСТЬ NULL)
ТОГДА Данные1.СуммаКонечныйОстаток * РАЗНОСТЬДАТ(Данные1.Период, МИНИМУМ(Данные2.Период), ДЕНЬ)
ИНАЧЕ Данные1.СуммаКонечныйОстаток * РАЗНОСТЬДАТ(Данные1.Период, ДОБАВИТЬКДАТЕ(&КонПериода, СЕКУНДА, 1), ДЕНЬ)
КОНЕЦ КАК Остаток
ИЗ
РегистрНакопления.ОстаткиТоваров.ОстаткиИОбороты(&НачПериода, &КонПериода, День, ДвиженияИГраницыПериода, Организация В (&МассивОрганизаций) И УсловияТорговли = (&У1)) КАК Данные1
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Обороты(&НачПериода, &КонПериода, День, Организация В (&МассивОрганизаций) И УсловияТорговли = (&У1)) КАК Данные2
ПО Данные1.Период < Данные2.Период И Данные2.СуммаОборот <> 0
СГРУППИРОВАТЬ ПО
Данные1.Период,
Данные1.СуммаКонечныйОстаток
) КАК ВЗ
) КАК Данные

Т.е. SQL запрос будет работать с уже кэшированными данными
В этом случае и ABAP справится быстро...

Согласен, семантика языков доступа к данным модели тоже не поменялась. А вот инструментарий 1С, реализующий эту семантику, поменялся радикально. Об этом, собственно, я и говорил.

Среднесуточные показатели являются важными в области анализа финансовых показателей предприятия, таких как
Показатели прибыльности:
Рентабельность средних активов по прибыли = чистая прибыль за период / все активы (среднесуточно)
Показатели деловой активности
Оборачиваемость активов = общий объем реализации товаров за текущий период / все активы (среднесуточно)

Могу привести еще массу подобных примеров.

Только зачем? Что эти примеры покажут\докажут?
Собственно как не понятно что доказывает приведённый ранее образец получения среднедневного чегото там, какие преимущества 1C он демонстрирует?