Форум MySQL

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

Конечно, если данные не сохраняются, овчинка выделки не стоит.

Так она и стаётся :) Просто в самом начале скрипта делается TRUNCATE TABLE обеим временным таблицам. Накапливать данные - такой задачи не стоит.

Это понятно, я о другом.
Меняется, как я понял, только чужой DBF. Почему нельзя оставить sql-копию своего (большого) файла до следующего раза?

Потому что у PHP'шного расширения для работы с DBF очень убогий набор функций, позволяющий разве что выбирать из БД записи перебором по порядку, либо по номеру конкретной записи. Соответственно делать поиск одинаковых записей в двух базах - это как ни крути цикл на 1500 записей внутри цикла на 8000 записей, ибо никаким языком запросов там и не пахнет... it's terrible!

Они оба в DBF?
Если большая база своя - зачем её каждый раз гонять из dbf в sql?

Потому что оно не нужно :) Скрипт удет работать в виде сервиса - зашёл, загрузил файл1 и файл2 (в оригинале они в DBF, перегоняются в mysql для удобства и скорости работы, т.к. записей в бОльшей базе очень много), нажал кнопочку - получил мгновенно результат - распечатал и доволен :)

А почему бы не ввести дополонительный столбец для идентификатора дочерней компании?

Да для работы просто надо - сверять отчёты, чтобы дочерние компании не наё***ли :))) Ну зачем вдаваься в подробности... простая автоматизация ручного труда!

Не хотите говорить значит. Ну ладно.

Цель проста - заливаются данные в две временные таблицы, нужно найти в этих двух таблицах идентичные записи.