Как отслеживать, какие строки были импортированы в SQL?

Question

Допустим, я хочу импортировать всех клиентов (или все строки в какой-то другой конкретной таблице) в какую-то внешнюю систему.Не все сразу, но каждый после того, как они были созданы в базе данных.Для этого мне нужно вести записи всех строк, о которых уже было сообщено, потому что я хочу найти только те, о которых еще не было сообщено.Как правило, для этого лучше добавить столбец или создать какую-то таблицу пакетного журнала?

Я использую MS SQL Server, если это уместно

Упрощенный пример:

выберите * у Клиента, для которого значение которого равняется null

или

выберите * у Клиента, для которого cus_id не указан (выберите cus_id из IntegrationBatchLog)

или, возможно, существуетбольше способов сделать это, что может быть еще лучше?Это первый раз, когда я делаю что-то подобное, поэтому пока не знаю лучших практик.

Answer 1

Простое решение - добавить столбец, который помечает строку как импортированную. Состояние int (0/1) или если вы хотите отслеживать, когда была импортирована дата импорта. Это решение имеет некоторые ограничения:

1. Вы можете импортировать строку только один раз. Вам нужно снова импортировать клиента при обновлении записи? Собираетесь ли вы очистить поле обновления при обновлении клиента?

2. Это приводит к блокировке строки при обновлении статуса строки. Вы уверены, что приложение, которое вставляет запись о клиенте, будет удовлетворено вашим кодом, блокирующим записи?

3. В некоторых системах это приводит к записи всей строки в систему журналов для восстановления. В зависимости от размера строки это может быть много записи журнала только для одного поля.

4. В высокопараллельной системе импорта вы можете испытывать большие разногласия за ресурсы. Если одна программа импорта блокирует таблицу, подумайте, как было бы плохо, если бы многие программы импорта блокировали таблицу одновременно.

5. Если данные клиента обновляются несколько раз в интервале опроса импорта, вы увидите только самые последние данные и пропустите промежуточные обновления. Это только проблема, если вы заботитесь о промежуточных обновлениях. Для клиентов вас это может не волновать, для статусов заказов вы можете быть очень внимательны.

6. Вы должны изменить структуру таблицы. Это может быть запрещено исходным приложением из-за проблем с данными / поддержкой / политиками.

Помимо размещения столбца состояния в таблице, один из методов, который работает хорошо, - это поместить триггер в таблицу и отразить данные импорта во второй таблице. Затем вы «потребляете» данные во второй таблице. Это имеет несколько преимуществ:

1. Сохраняет проблемы блокировки, содержащиеся во второй таблице.

2. Позволяет обрабатывать каждое обновление основной таблицы.

3. Вы можете добавить индекс ко второй таблице, который используется для отслеживания статусов обновлений без проблем с изменением основной таблицы.

4. Если вы удалите строки из второй таблицы (либо сразу после их использования, либо после короткого периода аудита), размер таблицы / индекса будет сведен к минимуму.

Когда я использую эту технику в Sql Server, я помещаю вторую таблицу в отдельную схему. Поскольку большинство приложений хранят свои таблицы в dbo, вы можете использовать dbo.Customers и Import.Customers. Это может помочь вам отследить, какие таблицы вы импортируете, и избавит вас от необходимости придумывать новые имена для ваших таблиц импорта.

Answer 2

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

В вашем случае я вижу только одну проблему при переходе от столбца к таблице.Если вам нужна история импорта.Решение: сделать reportedToExternalSystem столбец типа DateTime (или Timestamp)

Answer 3

Предпочитаю иметь column for importing status.Ведение отдельного журнала приводит к значительным затратам времени при увеличении размера таблицы.У меня есть концептуальная идея на SQL Server, но кажется, что она работает.Продолжайте писать!

Answer 4

Я бы использовал отдельную таблицу с указанием, скажем, даты импорта, перекрестно ссылающейся на ключ записи в отслеживаемой вами таблице. Другими словами, таблица с 3 столбцами: ключ автоинкремента, идентификатор записи из таблицы других данных, дата импорта. Что-то вроде того. Это также позволяет в случае повторной импорта записи позже. Вы бы отслеживали все импортные операции по дате.