Простые решения, простая жизнь!Такая инженерная задачка:
Написать скрипт синхронизации вашей базы и базы источника максимально удобно, без избыточных переменных и записей. Естественно, вам нужно сохранить у себя записи, которых в базе источника больше нету. Вы предусмотрительно создали колонку с указанием даты деактивации этой колонки на источнике
Речь идет о средней сложности интеграциях, не слишком быстрых и не слишком долгих
Вся сложность в том, что если вы при сихнронизации вы деактивируете все активные записи текущей датой, чтобы при последующем обновлении восстановить активные записи - вы получите временной лаг, когда у вас все учетные записи в какой-то момент времени будут деактивированы, что не всегда приемлимо, особенно когда записи активно используются, например в пользователях, либо товарах
Лечится это избыточностью
Если для вас критично время лага - вы можете создать копию таблицы, провести там полную замену и скоровать ее полностью на вашу рабочую таблицу. Если таблица большая - вы можете упереться в место на жестком диске, либо в ресурсы базы данных, особенно если база очень горячая. Но если горячая - вы можете обновлять данные пачками с определенной периодичностью.
Альтенративный вариант - вы собираете список всех id в память скрипта, далее проводите обычное обновление, вычеркивая из списка встречающиеся элементы. И все id что в списке остаются по окончанию синхронизации - вы можете спокойно деактивировать скопом. Здесь вы упираетесь в память, также особенно если таблица весомая, а сервер недостаточно мощный
Элегантный же способ пришел в голову - оставить первоначальный вариант с полной деактивацией записей, но не текущей датой, а датой со сдвигом на время отработки скрипта. Да это работает в случае, когда вам +- известно время полного обновления данных. Можно взять с запасом в большую сторону. После синхронизации записи прощуствуют до указанного времени сдвига и будут деактивированы автоматически
Да, если вы вовсе не используете дату, а только признак - то вариант вам не поможет