В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте

[mazzy]

Цитата:

Сообщение от Сисой

В ряде случаев (отбор по критерию "равно") 1С просто решает эту проблему по другому. В языке запросов 1С есть оператор В (IN), который умеет принимать в качестве операнда список объектных значений. Такой запрос автоматически транслируется 1С в объединение кучи одинаковых подзапросов с UNION ALL и подстановкой разных значений в условия сравнения. План запроса один и тот же.

Если честно, то похоже ты вообще не понял о чем речь.
Если кто-то может дать ссылки или объяснить в двух словах (проще, чем в статье), пожалуйста, сделайте это.

Цитата:

Сообщение от Сисой

За запросы в цикле на экзамене 1С:Специалист сразу дают по шапке.

Хнык-хнык-хнык... Опять начали что ли? Опять попытка смазать разницу между "уже есть" и "можно сделать"?

Да какая разница кто кому на каких курсах говорит?
В типовых запросы в цикле есть? Есть. Надо исправлять? Надо.
При чем здесь экзамен 1С:СПециалист?

Кроме того, мы говорим о платформе.
В том, то и дело, что в Аксапте иногда запрос в цикле выполняется быстрее и удобнее, нежели один сложный запрос. За счет кэширования.

Например,
Для каждого клиента/группы, для каждой номенклатуры/группы, для каждого рабочего центра и т.п... могут быть настроены свои правила разноски по счетам. Правила достаточно сложные. Объектов, для которых могут быть указаны правила разноски мжет быть до нескольких десятков.

Неужели создавать один суперсложный запрос для таких вещей?
Нет, отвечает Аксапта.
Сделайте правильный запрос для выборки объектов.
А правила разноски запрашивайте внутри. Поскольку правила скорее всего полностью попадут в кэш, то внутренние запросы выполнятся очень быстро.

Что кардинально упрощает программирование и взаимодействие объектов.
Псевдокод:

while select , , , , , , ...
where...
{
     = ();
     = ();
     = ();
    ...
    (, , ...);
}

И это будет гарантировано быстрым. Поскольку лишних запросов на SQL не будет.

Хочу обратить внимание, что код внутри цикла может быть распределен по другим методам, другим классам. Но он все равно будет быстрым из-за кэширования.

Хочу также обратить внимание, что правила могут быть любыми - не только счета. Но и правила расчета себестоимости, правила резервирвоания, правила работы со складскими аналитиками, куча настроек в производстве, офигенная куча настроек лдя сводного планирования... и т.п.

Понятно, что механизм кэширования тоже надо уметь настраивать.
Понятно, что механизм кэширования не спасет в случае больших таблиц.
У этого механизма есть своя область применения, где он работает очень хорошо.

В 1Се этого просто нет. Поэтому разработчики конфигураций вынуждены правила просто зашивать в код. Чтобы избежать ddos-атак на SQL. Или вручную кэшировать.

Цитата:

Сообщение от Сисой

Я по пальцам руки могу пересчитать случаи, когда реально результат отбора данных на шаге цикла зависит от предыдущих итераций.

Собственно об этом я и хотел сказать - бытие определяет сознание.
В 1С просто не делают по-настоящему настраиваемых конфигураций. Только программируемые

Цитата:

Сообщение от Сисой

Гораздо чаще можно отобрать необходимые данные в temptable (которая кэшируется на сервере 1С) и в цикле брать значения из нее.

Вот-вот
Отобрать и брать - это отдельный код, который тоже надо программировать.
за размером temptableтоже надо следить вручную