Лучший способ выполнить кодирование данных длины

Я создал таблицу, которая отслеживает различные атрибуты объектов с течением времени.

 Id | Attribute1 | Attribute2 | Attribute3 | StartDate  | EndDate
------------------------------------------------------------------
 01 |   100      |   Null     |   Null     | 2004-02-03 | 2006-04-30
 01 |   100      |   Null     |    D       | 2006-05-01 | 2010-11-06
 01 |   150      |   Null     |    D       | 2010-11-07 | Null
 02 |   700      |   5600     |   Null     | 1998-09-27 | 2002-01-27

Новые данные (~10 тысяч записей) поступают каждый день. Я хочу сравнить каждую запись с текущими данными для этого идентификатора, а затем:

а) Ничего не делать, если атрибуты совпадают. б) Если атрибуты отличаются, обновите текущую запись, чтобы EndDate была текущей датой, и создайте новую запись с новыми атрибутами. c) Создайте новую запись, если для этого идентификатора нет данных.

Мой вопрос в том, какой самый эффективный способ сделать это?

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

Будет ли это хорошим местом для использования курсора?


sql sql-server run-length-encoding
person Batman    schedule 20.06.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Как вы обрабатываете данные? По мере поступления или партиями?

Если это так, как оно приходит, то я бы сделал набор проверок наиболее вероятного атрибута для изменения и наименее вероятного (просто чтобы немного оптимизировать проверку) и обновил бы по мере необходимости. Десяток тысяч данных недостаточно, чтобы беспокоиться о слишком сильном замедлении. Это прямой подход.

Если вы обрабатываете как пакет (например, в конце рабочего дня каждый день), сортируйте данные по идентификатору, а затем по дате окончания по убыванию. Удалите все остальные экземпляры ID и заботьтесь только о последнем. Никакие промежуточные данные не будут иметь значения.

Пример: у вас есть 2 записи для идентификатора 1, одна с endDate 1 января, другая с endDate 25 января. Сначала посмотрите запись от 25 января и при необходимости обновите. Запись от 1 января слишком старая, чтобы беспокоиться о ней на тот момент.

person user3760445    schedule 20.06.2014