Сравнение исторических данных в реальном времени — быстрее в SQL или в коде?

У меня есть требование в проекте, над которым я сейчас работаю, чтобы сравнить самую последнюю версию записи с предыдущей исторической записью для обнаружения изменений.

Я использую платформу синхронизации данных Azure Offline для передачи данных с клиентского устройства на сервер, что приводит к обновлению записей в синхронизированной таблице в зависимости от изменений пользователя. Затем у меня есть триггер, копирующий каждое обновление в таблицу истории, и SQL-запрос, который запускается при построении списка изменений для сравнения текущей записи с самой последней историей путем сравнения столбцов — в основном строк, но некоторых целых чисел и значений даты.

Является ли это наиболее эффективным способом достижения этого? Не будет ли быстрее загрузить данные в память и выполнить сравнение на основе кода с правилами?

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


person RNDThoughts    schedule 26.01.2016    source источник
comment
Вы сравнивали два подхода, чтобы увидеть, какой из них быстрее работает с вашими данными?   -  person ChrisF    schedule 26.01.2016
comment
Пока нет, но это, конечно, следующий шаг! Просто искал общий совет.   -  person RNDThoughts    schedule 26.01.2016


Ответы (2)


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

Рассмотрим основную таблицу с 50 000 записей и 1 000 000 записей исторических данных (и она растет с каждым днем).

Вместо того, чтобы напрямую обновлять основную таблицу, а затем запрашивать 1 000 000 записей (и извлекать самую последнюю запись), вы можете запросить меньшую основную таблицу для этой записи (возможно, идентификатора), сравнить поля и только если есть изменение (или пока нет данных) обновляет эти поля и добавляет запись к историческим данным (или использует для этого триггер/хранимую процедуру).

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

person Danny_ds    schedule 26.01.2016
comment
Структура синхронизации, которую я использую, имеет дело с фактическими изменениями данных, поэтому я получаю новые записи истории только тогда, когда происходит фактическое изменение. Учитывая пакет обновлений ряда записей, мне нужно сравнить все изменения с их предыдущим состоянием и создать выходной список того, что изменилось. - person RNDThoughts; 26.01.2016

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

person RNDThoughts    schedule 20.10.2016