Доброй ночи, коллеги!

Буду благодарен, если подскажете идею.

Есть некая таблица Table1 с неключевыми полями F1 и F2. Каждая строка этой таблицы имеет уникальный ключ.
Формируем другую таблицу Table2 с одним неключевым полем F1, в которой каждая строка имеет уникальный ключ.
Необходимо выполнить объединение этих двух таблиц:
1. во всех строках Table1, которые по уникальному ключу имеют соответствующие строки из Table2, заменить значение поля F1 на значение поля F1 из строк Table2
2. во всех строках Table1, которые по уникальному ключу НЕ имеют соответствия в Table2, обнулить поле F1
3. добавить в Table1 новые строки из Table2, которых по ключу нет в Table1. При этом поле F2=0.
4. удалить из Table1 строки, в которых оба поля F1 и F2 одновременно равны нулю или NULL

Я описал алгоритм примерно так, как я эту задачу решал на десктопной базе - минимизация операций модификации Table1.
Table2 формировалась в памяти.

Сейчас хочу этот алгоритм оптимизировать к sql-базе. Table2 планирую формировать в хранимке как временную на движке MEMORY.
Обращаю внимание, что просто заменить Table1 на Table2 нельзя из-за того, что в Table1 кроме поля F1 есть еще поле F2, которое не присутствует в Table2!

Пока вижу решение, которое, имхо, не совсем подходит для sql-базы:
1. обходим курсором Table1, "дергаем" по ключу Table2 и меняем значение поля F1 в Table1 в зависимости от результата "дергания" Table2. Одновременно удаляем из Table2 запись, которая "выдернулась".
2. добавляем в Table1 все оставшиеся записи из Table2, заполняя поле F2 NULL-ем:

3. выполняем:

В этом алгоритме мне совершенно не нравится пункт 1!

В дополнение к первому посту.

Что "легче" для сервера - удаление строк из временной таблицы или изменение зачения одного поля?
Т.е., если модифицировать пункты 1 и 2 из окончательного алгоритма:
1. Вместо удаления "выдернутой" записи Table2 просто выставить значение поля Del=1
2. Добавлять из Table2 не все строки, а только строки с Del=0. Да еще и сразу проверять поле F1:


В принципе, остается оптимизация пункта 1 - как одним запросом изменить записи Table1 на такие-же (по ключу) записи из Table2?
Точнее - не полностью запись, а только одно ее поле F1.
Если такой запрос удастся составить, то тогда прийдется еще и сочинить запрос для пункта 2 - добавить в Table1 записи из Table2, которых (по ключу) нет в Table1.

В общем - буду благодарен конструктивным идеям!

tanglirOlegROA4. удалить из Table1 строки, в которых оба поля F1 и F2 одновременно равны нулю или NULLНеужели у вас даже с этим есть сложности? Про функцию ifnull и оператор and не знаете?
Вы, вероятно, не совсем внимательно прочитали мои два сообщения - в SQL-алгоритме решения (пункт 3) я этот запрос как раз и написал.
tanglirOlegROAЧто "легче" для сервера - удаление строк из временной таблицы или изменение зачения одного поля?OlegROATable2 планирую формировать в хранимке как временную на движке MEMORY .Ну сами подумайте, что легче - долбить диск или обращаться к ОП?Никакого "долбления" диска нет - я рассматривал все эти операции во временной таблице! Понятно, что если вся временная таблица помещается в памяти, то разница во времени между UPDATE и DELETE будет ничтожной.
Поэтому этот вопрос я задал в общем, применительно к обычным InnoDB-таблицам - что в них менее "напряжно" для сервера и быстрее - UPDATE или DELETE?

А за алгоритм решения - большое спасибо!

Правда, все равно получаем три пункта, в которых каждый раз приходится серверу полностью читать или сразу обе таблицы или, как минимум, одну из таблиц:
Второй пункт можно не учитывать - производится чтение временной таблицы в ОП.
А вот первый и третий предполагают чтение всей InnoDB-таблицы дважды!

В моем старом алгоритме для десктопной базы удаление и обновление Table1 выполнялось за один проход.
Неужели никак нельзя совместить UPDATE с DELETE - указать серверу что бы обе операции выполнялись за один обход этой таблицы?

Спасибо!

AkinaOlegROAВ моем старом алгоритме для десктопной базы удаление и обновление Table1 выполнялось за один проход.Да ладно... на MySQL?Нет, конечно! Десктопная база - обычный "движек" типа Btrieve или DBF - Topspeed. Обычное хранилище данных с ключами/индексами. Вся логика - в клиентской программе.
Алгоритм обработки таких баз чем-то напоминает курсоры в SQL. Или, скорее всего, HANDLER в MySQL.
Выборка, если можно так сказать, формируется за счет ключей/индексов - обходим только записи, попавшие в нужный ключ.
Ну, и здесь сразу в зависимости от условий или изменяем запись или удаляем ее.