Отслеживание изменений данных SQL Server и отображение состояния данных в заданное время

У меня есть довольно специфическая проблема, для которой я не могу найти работоспособного решения (это веб-приложение ASP.NET с SQL Server 2008 R2).

Допустим, у нас есть 3 элемента (таблицы) с некоторыми данными. Нам нужно отслеживать изменения данных по этим элементам.

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

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

Есть ли какое-либо передовое решение для этого или чего-то еще, что не потребовало бы написания сложной иерархии функций/процедур T-SQL (которая всегда будет занимать очень много времени), чтобы собрать данные вместе?

Спасибо за любой совет!

ИЗМЕНИТЬ:

У нашего клиента 700 тыс. строк в файле xls (4 типа элементов, смешанных вместе .. кошмар: D).

Мы хотим обработать его и сохранить в базе данных.

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


person Lucas    schedule 07.08.2018    source источник
comment
Ха ... действительно зависит от вашего набора данных и от того, сколько записей вам нужно обработать. Возможно, можно было бы сделать составной ключ из вашего (существующего?) идентификатора/первичного ключа и метки времени. Таким образом, вы могли бы получить «самое новое» как текущее состояние объекта, а также сохранить изменения. Вы также можете получить все записи при фильтрации таблицы только по pk и увидеть все изменения, внесенные в запись. Ну, избыточность - это проблема.   -  person nilsK    schedule 07.08.2018
comment
Здравствуйте, спасибо за ваш комментарий - у нас есть исходный файл xls (который будет импортирован в базу данных) с 700 тыс. строк. Он будет синхронизироваться каждые несколько дней со всеми изменениями данных, по нашим оценкам, каждые несколько дней меняется от 100 до 1000 строк. Так что, я думаю, записи будут масштабироваться довольно быстро.   -  person Lucas    schedule 07.08.2018
comment
Составной ключ - довольно интересное предложение - мы попробуем создать модель таким образом и изучим ее, возможно ли это решение в нашей среде, спасибо! :)   -  person Lucas    schedule 07.08.2018
comment
Добро пожаловать, удачи! знак равно   -  person nilsK    schedule 07.08.2018
comment
Триггеры & и Таблица журнала изменений с первичным ключом отслеживаемой таблицы, датой модификации и измененным значением.   -  person Cleptus    schedule 07.08.2018


Ответы (1)


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

Мы придумали решение, с помощью которого мы можем:

- показать данные элемента в заданное время (довольно быстро, только выбрав D1 или D2 из таблицы обновления)
- получить "жизненный цикл" любого выбранного элемента во времени (клиент хочет показать жизненный цикл всего элемента/ row)

Что мы не можем сделать (это не было первоначальным запросом для этой задачи, но мы использовали его в прошлом)

- быстро получить конкретные изменения столбцов для данного элемента, потому что они не отслеживаются, а только элемент целиком, но при необходимости их можно получить путем обратного отслеживания в таблице Element по ID и ParentID

Структура БД

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

person Lucas    schedule 07.08.2018