Если источник только для вставки, укажите IDENTITY
столбец. Когда вы выполняете передачу данных, вы записываете наибольшее значение, записанное. Во время следующей передачи вам нужно только запросить значения, которые были больше, чем во время предыдущей передачи. Мы делаем это для передачи записей журнала в хранилище данных.
Для обновляемых строк добавьте «грязный» флаг. Он будет иметь три значения - чистый, грязный и удаленный. В повседневных запросах нужно будет пропустить строки с установленным флагом «удалено». Это будет дорого в обслуживании, тестировании и во время выполнения. После большого запроса вы упоминаете, что все строки, помеченные для удаления, должны быть удалены, а флаг сброшен для всех остальных. Это не будет хорошо масштабироваться.
Более легкой альтернативой для сбора данных изменений является отслеживание изменений . Он не скажет вам, какие значения изменились, только то, что строка изменилась с момента последнего запроса. Встроенные функции облегчают поиск измененных значений и управление отслеживанием. Мы успешно использовали CT для обработки около 100 000 изменений в день в таблице 100 000 000 строк.
Уведомления о запросах действуют еще выше - на уровне набора результатов. Концептуально это похоже на определение представления. Если SQL Server обнаруживает, что любая строка, возвращенная через это представление, изменилась, он запускает сообщение для приложения. Не указано, сколько строк изменилось или какие столбцы. Есть только простые сообщения, говорящие «что-то случилось». Это зависит от приложения, чтобы узнать и отреагировать. Практически это намного сложнее, чем вы можете себе представить. Существуют ограничения на то, как запрос может быть определен, и уведомление может запускаться для условий, отличных от измененных данных. Когда уведомление срабатывает, оно удаляется. Если дальнейшая интересующая деятельность произойдет впоследствии, дальнейшее сообщение не будет отправлено.
В контексте вопроса OP, QN будет иметь преимущество, заключающееся в том, что он требует минимальных накладных расходов и требует небольших затрат времени выполнения. Это может быть значительное усилие, чтобы установить и поддерживать строгий режим подписки-сообщения-реагирования. Поскольку таблица данных велика, вероятно, в ней будут частые изменения, а это означает, что уведомление может срабатывать в большинстве циклов обработки. Поскольку нет указаний на то, что изменилась инкрементная обработка дельт, будет невозможно, как это было бы с CT или CDC. Накладные расходы из-за ложных срабатываний являются утомительными, но даже в худшем случае дорогой запрос не нужно выполнять чаще, чем в настоящее время.