Древовидная структура с историей в SQL Server

Question

Я не уверен, что это дублирующий вопрос, но я не смог найти ничего по этому вопросу.

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

Спасибо за любую помощь.

ОБНОВЛЕНИЕ:

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

ОБНОВЛЕНИЕ 2:

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

ОБНОВЛЕНИЕ 3:

Там также Заказы Таблица.Я должен хранить должность сотрудника, филиал, отдел, раздел, подраздел и другое в каждом заказе.Это главная причина хранения истории.Это будет использоваться очень часто.Другими словами, я должен иметь возможность отображать данные в БД за каждый прошедший день.

ОБНОВЛЕНИЕ 4:

Может быть, использование иерархии - это вариант?

Что если узел переименовать?Что мне делать, если мне нужно старое имя на старых заказах?

Answer 1

Я думаю, вы ищете что-то подобное.Это обеспечивает полную древовидную структуру.Это используется для каталога, но может использоваться для чего угодно: отделов, отделов, разделов и т. Д.

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

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

Для (b) я бы реализовал производную версию таблицы (Node, Department, что угодно), котораявозвращает строки, которые были текущими в соответствующий момент времени;затем используйте это для исторической версии (a).

Нет необходимости копировать и сохранять всю древовидную структуру каждый раз, когда она изменяется.

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

Модель данных

▶ Древовидная структура с моделью данных истории ◀

Читатели, не знакомые с реляционным моделированиемСтандарт может найти ▶ IDEF1X Обозначение ◀ полезно.

Answer 2

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

Учитывая, что мы говорим об иерархии сотрудников, могу поспорить, что решения для аудита будет достаточно.В решении по аудиту у вас есть одна таблица (таблицы) для текущей иерархии и вы можете сохранить изменения в другом доступном месте.Следует отметить, что «где-то еще» не обязательно должно быть данными.Если изменения в иерархии компании происходят нечасто, вы даже можете использовать серьезно низкотехнологичное решение для создания отчета (или серии отчетов) иерархии компании и сохранения его в формате PDF.Когда кто-то хотел узнать, как выглядит иерархия в прошлом мае, он мог найти соответствующую распечатку в формате PDF.

Однако, если желательно, чтобы контрольный журнал запрашивался, вы могли бы рассмотреть что-то вроде функции отслеживания изменений SQL Server 2008 или стороннего решения, которое делает нечто подобное.

Помнитечто в вопросе о «лучшем» есть нечто большее, чем сама структура.Существует анализ затрат и выгод того, сколько усилий требуется в сравнении с предоставляемыми функциями.Если заинтересованным сторонам необходимо запрашивать иерархию в любой момент времени, и она часто колеблется (не хотелось бы там работать :)), временное решение может быть лучшим, но его внедрение будет более затратным.Если иерархия меняется нечасто и детальный аудит не требуется, то я был бы склонен просто периодически хранить PDF-файлы иерархии.Если есть реальная необходимость запрашивать изменения или требуется детальный аудит, я бы посмотрел на инструмент аудита.

Отслеживание изменений

Выполнение быстрого поискаВот пара сторонних решений для аудита:

ApexSQL

Lumigent Technologies

Answer 3

Стоит заметить, что вы не хотите историзовать древовидную структуру. Он всегда только растет, никогда не становится меньше.

Что искажает, так это использование узлов. Их данные могут измениться.

Например, сайт.

/ а / б / с

будет там навсегда. A может быть папкой, b тоже c файлом. Позже a может быть фолтером, b надгробной плитой (здесь пока нет данных) как c. Но дерево само по себе никогда не меняется.

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

Код для отображения версии X затем может легко построить «настоящее» дерево для этого момента.

Для поддержки перемещений узлов используйте тип rehook, который указывает, что noe был перемещен в другой элемент в этой версии.

Вуаля.

Answer 4

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

ОБНОВЛЕНИЕ: на основена вашей новой информации я бы не использовал единственное хранилище табличных данных, похоже, что ваша иерархическая структура намного сложнее простого дерева, а также выглядит так, как будто у вас есть несколько четко определенных узлов структур, особенно наверху, прежде чем попасть вразделы и подразделы;поэтому отношения с несколькими таблицами могут быть более подходящими;

Что касается таблиц аудита, есть много ресурсов, чтобы выяснить, что будет работать лучше для вас, есть аудиты на ряд и на столбец и т. д.