В настоящее время я использую Adjacency List Model с моими иерархическими данными в базе данных SQL, и я собираюсь изменить его на Nested Set Model, чтобы исключить мою рекурсивную обработку, когда у меня несколько уровней.
ЭтоДанные используются для представления дерева, заполненного объектами высокого уровня, которые мы хотим представить и использовать в другой части нашей системы.Мы хотим использовать это для повышения целостности данных, универсального определения и т. Д. Мы разрешаем пользователям в управляемом пользовательском интерфейсе добавлять новые объекты, новых дочерних элементов к существующим объектам и перемещать объекты для создания-->
реальное и полное видение нашего мира данных .
Проблема:
Мы хотим отслеживать (с помощью point in time), где и что были данные до изменения.Мы хотим иметь возможность создавать отчет о том, что это были за данные и что это сейчас.
Прямо сейчас, для этого мы используем Chronological Table, который просто заполняется новыми записями, состоящими изте же объекты, но с разными данными, датой начала и датой окончания.Поэтому каждый раз, когда объект (узел) перемещается под новым родителем, его данные меняются (например, описание, имя и т. Д.), Мы добавляем новую запись в таблицу.Таким образом, таблица будет просто ужасно большой и, вероятно, будет содержать избыточность ..
Почему:
Я не уверен, что наличие избыточности иБольшой набор данных в моей Хронологической Таблице - эффективный способ сделать это.
Вам, ребята, приходилось иметь дело с такими данными раньше?Что ты сделал?Как вы думаете?
Я хочу знать, могу ли я реализовать это по-другому?Есть ли лучший способ управления изменениями данных во времени?
[Изменить]
Пример:
Каждый узел имеетнабор столбцов (около 20) (свойств), которые можно использовать, чтобы помочь людям с определениями, текстом справки, родителем, сортировкой или даже просто именем самого узла.
Так что мне нужно отслеживатьэти данные, мне нужно иметь возможность знать, где они были в иерархии, прежде чем они меняются местами, мне нужно знать их имя раньше, мне нужно знать все на этом узле .. Но если что-то меняется, мне нужно добавить новыйзапись с новой действительной датой начала для того же узла, но все данные будут повторяться, если они не изменились.Таким образом, если родитель изменился, родительская ссылка обновляется, но все остальное является избыточностью.
Хронологическая таблица
Итак IDявляется уникальным идентификатором для хронологического и UID для самого объекта.Мы также планировали добавить все текстовые значения для узла в хронологическую таблицу.
Итак, представьте, что через 5 лет объект (UID) 15 изменился, как 1000 раз, 1000 новых записей.