Для данной таблицы в моей системе записи (СУБД) мне нужно реализовать функцию для постепенного экспорта записей. Например, если пользователь запускает задание экспорта, которое возвращает x количество записей, я хочу вернуть пользователю идентификатор снимка. Для следующего задания экспорта пользователь передаст мне этот идентификатор снимка, и с его помощью я смогу экспортировать только те записи, которые были изменены или добавлены с тех пор. В идеале я бы хотел, чтобы идентификаторы моих снимков можно было использовать повторно. Другими словами, я не хочу, чтобы срок действия идентификаторов моих снимков истек, но это не является жестким требованием.

Учитывая, что во всех моих таблицах есть столбец LAST_UPDATE_DATE (Timestamp), как лучше всего решить эту проблему?

Я не ищу код, инструменты или команды. Я просто ищу логику того, как я должен сгенерировать этот идентификатор снимка и распознать его в последующих вызовах для выполнения инкрементного экспорта записей в данной таблице.

0
RHT 4 Май 2013 в 02:11

1 ответ

Лучший ответ

Отметки времени, очевидно, являются глобальными, поэтому идентификатор снимка должен быть только одной отметкой времени. Например, в SQL Server вы можете запустить SELECT CURRENT_TIMESTAMP, чтобы получить текущую метку времени.

Если вы хотите экспортировать, запустите отдельные запросы для каждой таблицы, чтобы экспортировать строки, у которых есть отметка времени между последней экспортированной и текущей. Если поля отметок времени проиндексированы, каждый из этих запросов должен быть довольно быстрым, очевидно, в зависимости от объема данных, которые нужно экспортировать.

Предполагая, что вы запускаете этот экспорт, в то время как другие обновления в базе данных могут происходить, важно, чтобы вы получили текущую метку времени только один раз, сохранили ее как переменную и работали с этим значением (в отличие от свободного использования, например, CURRENT_TIMESTAMP), в противном случае некоторые данные время от времени будут пропадать.

Возможно, вы захотите установить флаг столбца Deleted в каждой таблице и обновить его, а не удалять строки, чтобы вы знали, какие строки были «удалены».

1
Bernhard Barker 4 Май 2013 в 04:25
Спасибо, отличные предложения. Клиент может сохранить current_timestamp, используемый в качестве потолка для задания экспорта, и он станет отправной точкой, то есть меньшим значением для следующего запуска. Мне также нравится идея отсутствия физического удаления, иначе я бы не знал, какие записи были помечены для удаления. Это выглядит простым в реализации и, вероятно, станет общепринятым ответом.
 – 
RHT
4 Май 2013 в 09:13