Общая стратегия управления версиями для выбора табличных данных в сильно нормализованной базе данных - PullRequest
5 голосов
/ 03 марта 2009

Извините за длинный заглавный титул, но требование / проблема довольно специфичны.

Со ссылкой на следующую примерную (но очень упрощенную) структуру (в psuedo SQL) я надеюсь объяснить ее немного лучше.

TABLE StructureName {
  Id GUID PK,
  Name varchar(50) NOT NULL
}

TABLE Structure {
  Id GUID PK,
  ParentId GUID,                 -- FK to Structure
  NameId GUID NOT NULL           -- FK to StructureName
}

TABLE Something {
  Id GUID PK,
  RootStructureId GUID NOT NULL  -- FK to Structure
}

Как видно, структура - это простая древовидная структура (не заботящаяся о порядке детей для задачи). StructureName - это упрощение системы перевода. Наконец, «Нечто» - это просто нечто, ссылающееся на корневую структуру дерева.

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

Существует требование к версии для любых изменений имени и / или дерева «макет» таблицы структуры. Предыдущие версии всегда должны быть доступны.

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

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

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

Любые идеи будут высоко оценены.

Спасибо

leppie

Ответы [ 2 ]

10 голосов
/ 03 марта 2009

Несколько быстрых идей:

Полная копия: Создайте копию структуры, но для каждой таблицы добавьте столбец version_id в PK и все FK; таким образом, вы можете создавать копии данных о жизни с полной ссылочной целостностью.

  • Pro: легко запросить историю
  • con: большое количество (скопированных избыточных данных)

Изменить копию: Скопировать только то, что действительно изменяется, вместе с valid_from / valid_to данными.

  • pro: низкий объем данных скопирован
  • con: сложный запрос, потому что нужно соединяться с интервалами

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

  • pro: меньшее количество таблиц, более легкое смешивание истории и текущей информации
  • con: нормальная работа работает на гораздо больших столах, что может повлиять на производительность

Журнал аудита: В зависимости от ваших реальных требований достаточно просто создать контрольный журнал, подобный этому:

id,  timestamp,  changed_table,  changed_column,  old_value,  new_value,  changed_by

Вы можете расширить это до полной структуры таблицы:

transaction,  table_change,  changed_column
  • pro: универсальный, следовательно, простой в реализации для большого количества таблиц
  • con: если вам нужно восстановить состояние набора записей в определенный момент времени, запрос станет кошмаром

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

6 голосов
/ 03 марта 2009

У пользователей хранилищ данных есть несколько алгоритмов для "медленно меняющихся измерений".

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

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

  1. Назначение номера версии строкам таблицы структуры. Это означает, что вы должны сделать некоторые рассуждения, чтобы собрать полную структуру. Он включает выбранный номер версии, объединенный со строками, которые не изменились в более ранней версии.

  2. Назначить диапазон дат или диапазон версий строкам таблицы структуры. Это означает, что некоторые строки имеют даты начала и окончания; некоторые строки будут иметь конечные даты в какой-то эпохе в невозможном будущем. Или, если вы используете номера версий, у вас будет пара начало-конец или пара начало-бесконечность, которая указывает, что эта строка все еще актуальна. Затем можно тривиально запросить строки, которые действительны «сегодня», или применить к запрашиваемой версии.

  3. Клонировать структуру для каждой версии. Это неприятно, потому что операция клонирования является дорогостоящей. Однако запросы тривиальны, потому что вся структура доступна с одним, согласованным номером версии.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...