Ответ

Misha v.3 27.05.2015 11:57 / 27.05.2015 11:58

В вашем примере:
1. Первую таблицу надо прокрутить 2 раза (для получения второй таблицы и формирования отчета).

ну как бы нет.
по ней делаем menu только один раз, при выводе.

2. Вторую таблицу надо прокрутить 1 раз (для получения третьей таблицы) + сделать из нее хеш таблиц, который потом надо будет прокручивать на каждый заказ по ключу хеша.

как бы тоже нет.
явно -- один раз, при выводе.
неявно -- дважды. второй раз при создании из неё хэша таблиц.
в вашем коде, кстати, я не видел хэша таблиц вообще. я видел хэш хэшей:

^СписокЗаявок.[$СписокЗаказов.номер_заявки].foreach[key;value]{...}

3. Третья таблица получается сразу в виде хеша таблиц, который потом надо будет прокручивать на каждую дочернюю заявку по ключу хеша.

хм. я и забыл, что парсер так умеет :)
но на самом деле это то-же самое, что получение таблицы и последующее получение из неё хэша таблиц.

В итоге получаем 4 объекта:

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

была мысль взять вторую и третью таблицы одним запросом, который превратить в хеш хешей таблиц

так вы потратите много памяти на передачу от sql сервера, т.к. при join количество строк увеличится и будут переданы дублирующиеся текстовые строки, которые вам по сути не нужны.

Мне казалось, что конструкция
...вложенный хэш лукап...
будет работать быстрее, чем вызов
...contains + locate...

да, она будет быстрее почти всегда. contains (вызов метода) + locate (ещё один вызов метода с линейной зависимостью от количества записей, как уже упомянул moko@) будет однозначно медленнее при большом кол-ве строк в таблицах.

P.S. я закончил, т.к. я до конца так и не понял структуру ваших данных, а без этого обсуждать нечего. код для создания вашего вложенного хэша я тоже не понял, для меня он "мутный", странный и черезчур сложный, но оценить его корректность/оптимальность я не могу, т.к. не понимаю структуру данных.

---