Иван FXSКакой способ предпочтительнее, при условии, что даже каждая из исходных таблиц уже является большой - в том смысле, например, что не вмещается в оперативную память компьютера?А почему не третий, сразу написать запрос, берущий данные из всех таблиц без каких-либо копирований ? СУБД обычно и так неплохо умеют работать в условиях нехватки памяти.

Иван FXSВ смысле - UNION? Но это, я так понимаю, разновидность 2-го варианта, поскольку Engine сольет все в одну (временную) таблицу, которую потом будет группировать.Не уверен, очень многое зависит от СУБД и оптимизатора запросов. Промышленные СУБД, как правило, имеют алгоритмы для работы с данными, не помещающимися в ОЗУ, с минимизацией обращения к файлам. Ваше право - попытаться облегчить работу для СУБД, но, возможно, сначала стоило бы дать шанс СУБД, не исключено, что у нее это лучше получится. В конце концов, их для этого и пишут :)
Искренне сожалею, но вряд ли смогу Вам помочь выбрать лучший вариант, так как есть сильная зависимость от конкретной ситуации. Например, 2 вариант невозможен, по причине нехватки свободного дискового пространства для копирования всей информации в одну таблицу. Да и копирование такое может потребовать неслабой дисковой активности, по типу, прочитал здесь, записал там, опять же, логирование может сильно увеличить нагрузку на диск. Поэтому 1 вариант выглядит несколько привлекательней, но у него могут быть свои трудности. В принципе, лучше один раз пройтись по одной таблице, чем много раз по разным, хотя бы потому что может пострадать общая эффективность физического чтения из-за невозможности упреждающего чтения. Опять же результаты придется тоже писать, а потом выполнять еще одну группировку. Насколько часто придется выполнять эту процедуру, какая активность будет на сервере, OS, СУБД, hardware, RAM, сколь велико отношение объема таблиц к ОЗУ, какие индексы, если используются ? В общем, нюансов масса и не уверен, что их можно учесть все, по крайней мере, в общем случае :) Так что, IMHO, если есть возможность, а процедура повторяющаяся, то, наверное, лучше проверить все варианты, хотя бы по разу. Не исключено, что в Вашей ситуации только один из вариантов окажется абсолютным победителем, хотя, повторюсь, сначала стоит дать шанс СУБД, вдруг результат Вас вполне устроит ?