Ответ

virusav 27.05.2015 09:18

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

В итоге получаем 4 объекта:
1. Таблица 1 в виде table (2 полных прокрутки через menu).
2. Таблица 2 в виде table и hash table (1 полная прокрутка table и прокрутка хеша таблиц на каждую дочернюю заявку).
3. Таблица 3 в виде hash table (прокрутка хеша таблиц на каждую дочернюю заявку).

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

$hData.[заказы.номер_заявки].[заявки.номер_дочерней_заявки].[номер_заказа].поле_из_таблицы_подключения

будет работать быстрее, чем вызов

^if(^Подключения.contains[заявки.номер_дочерней_заявки] && ^Подключения.[заявки.номер_дочерней_заявки].locate($Подключения.[заявки.номер_дочерней_заявки].номер_заказа==$Заказы.код && $Подключения.[заявки.номер_дочерней_заявки].поле1_из_таблицы_подключения==...)){
	$Подключения.[заявки.номер_дочерней_заявки].поле2_из_таблицы_подключения
}

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

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

---