управление строками истории в базе данных

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

Если бы у меня есть 1 или 2 таблицы истории для хранения, я сделал бы это точно, как Tuinstoel предположил. Но если бы у Вас были десятки таблиц, чтобы сделать это на, то я переместился бы больше к решению, описанному zendar. Причина - это.

Как Вы отвечаете на вопросы как,

• Что изменилось с тех пор вчера, когда все было прекрасно?

• Есть у пользователя SMITHG, внес какие-либо изменения?

Те вопросы требуют одного запроса на таблицу, является ли это отдельной _hist таблицей или разделом в таблице. Неважно, это - некоторый огромный список запросов. Если у Вас есть центральная таблица, которая похожа на это, то это - часть круга.

table_name, Column_name, PK, Before_value, After_value, User, timestamp

Вставляет имеют только после значений,

Удаляет имеют только перед значениями,

Обновление имеет обоих, но только для столбцов, которые изменились.

Некоторые изменения

Можно включать столбец для I/U/D, если Вы предпочитаете, чтобы можно было исключить значения столбцов для Вставок и просто записать PK и меня, так как правильные значения находятся все еще в таблице.

Так как это - Oracle, которую Вы могли разделить на table_name, так в сущности у Вас на самом деле есть тот тсс "таблицей" на реальную таблицу.

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

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

Я не использовал его, но это выглядит способным.

Первый вопрос должен быть: что Вы сделали бы с теми данными? Если у Вас нет ясного бизнес-требования, не делайте этого.

Я сделал что-то подобное и после 3 лет выполнения существует приблизительно 20% "допустимых данных", и отдых является "предыдущими версиями". И это - 10 миллионов + 40 миллионов записей. За прошлые три года у нас было 2 (два) запроса для исследования истории изменений, и запросы обоих раз были глупы - мы записываем штамп времени рекордного изменения, и нас попросили проверить, работали ли люди сверхурочно (после 17:00).

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

Править:

Так как Вы попросили возможные решения, я опишу то, что мы сделали. Это несколько отличается, чем решение, которое Вы рассматриваете.

1. Все таблицы имеют суррогатный первичный ключ.
2. Все первичные ключи сгенерированы от единственной последовательности. Это хорошо работает, потому что Oracle может генерировать и числа кэша, таким образом, никакие проблемы производительности здесь. Мы используем ORM, и мы хотели, чтобы каждый объект в памяти (и соответствующая запись в базе данных) имел уникальный идентификатор
3. Мы используем ORM и отображающуюся информацию между таблицей базы данных, и класс находится в форме атрибутов.

Мы записываем все изменения в единственной архивной таблице со следующими столбцами:

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

Вещь прокладывает себе путь:

• ORM имеет, вставляют/обновляют и удаляют команды.
• мы создали один базовый класс для всех наших бизнес-объектов, которые переопределения вставляют/обновляют и удаляют команды
  • вставьте/обновите/удалите команды, создают строку в форме пар имени поля/значения с помощью отражения. Код ищет отображающуюся информацию и читает имя поля, присваиваемое значение и тип поля. Затем мы создаем что-то подобное JSON (мы добавили некоторые модификации). Когда строка, представляющая текущее состояние объекта, создается, это вставляется в архивную таблицу.
• когда новый или обновленный объект сохраняется к таблице базы данных, он сохраняется к его целевой таблице и в то же время, мы вставляем одну запись с текущим значением в архивную таблицу.
• когда объект удален, мы удаляем его из его целевой таблицы и в то же время, мы вставляем одну запись в архивную таблицу, которые имеют тип транзакции =, "УДАЛЯЮТ"

Pro:

• у нас нет архивных таблиц для каждой таблицы в базе данных. Мы также не должны волноваться об обновлении архивной таблицы, когда схема изменяется.
• полный архив разделяется от "текущих данных", таким образом, архив не налагает производительности, пораженной в базу данных. Мы помещаем его на отдельную табличную область на отдельном диске, и это хорошо работает.
• мы создали 2 формы для просмотра архива:
  • общее средство просмотра, которое может перечислить архивную таблицу согласно фильтру на архивной таблице. Пользователь данных фильтра может ввести в форму (отрезок времени, пользователь...). Мы показываем каждую запись в имени поля/значении формы, и каждое изменение является кодированным цветом. Пользователи видят все версии для каждой записи, и они видят кто и когда внесенные изменения.
  • средство просмотра счета - этот был сложен, но мы создали форму, которая показывает счет, очень похожий на исходную форму ввода счета, но с некоторыми дополнительными кнопками, которые могут показать различные поколения. Это приложило значительные усилия для создания этой формы. Форму использовали несколько раз и затем забыли, потому что это было не нужно в текущем рабочем процессе.
• код для создания записей архива расположен в единственном классе C#. Нет никакой потребности в, включает каждую таблицу в базе данных.
• производительность очень хороша. В пиковое время система используется приблизительно 700-800 пользователями. Это - приложение ASP.NET. И ASP.NET и Oracle работают на одном двойном XEON с 8 ГБ RAM.

Недостатки:

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

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

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

Есть ли некоторая конкретная причина, Вы не хотите использовать то, что, кажется, обычное решение этой ситуации?

Как Вы определите первичные ключи? Будет много строк с тем же первичным ключом из-за хранения строк истории в той же таблице.

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

(Один проект, я продолжил работать, мы генерировали все таблицы истории и триггеры с помощью codesmith, это работало очень хорошо.)

Я использовал бы IS_LAST=1 раздел, и IS_LAST=0 система раздела. Поскольку это делится, это будет быстро (сокращение раздела), и Вы никогда не должны будете запрашивать объединение нормальной таблицы и таблицы истории.

Я использовал бы IS_LAST ='Y'/'N' и не 1/0. 1 и 0 бессмысленны.

Существует специальный прием, который может помочь гарантировать, что там макс. одна строка с IS_LAST='Y' на объект: можно создать уникальный основанный на функции индекс с функцией, которая возвращает пустой указатель когда IS_LAST='N' и возвратите идентификатор когда IS_LAST='Y'. Это объяснено здесь: http://www.akadia.com/services/ora_function_based_index_1.html

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

Все зависит от того, что у вас есть:

• Вы используете Standard или Enterprise Edition? Разметка включена только в качестве опции поверх Enterprise Edition. Подробнее об этом здесь .
• Вы можете рассмотреть возможность использования Workspace Manager , если вы ищете простое решение, в котором вам не нужно поддерживать свой собственный код. , Однако есть некоторые ограничения, которые я обнаружил (например, обслуживание индекса Oracle Text кажется трудным, если не невозможным, хотя я смотрел на него только на 10gR2).
• В противном случае, я бы выбрал решение любого из зволков (живая таблица). с записью триггера в таблицу истории) или решением Марка Брейди (журнал изменений). Я использовал оба шаблона, и у каждого есть свои плюсы и минусы.
• @zendar: Флэшбэк запрос работает только тогда, когда вы отменили. Это не долгосрочное решение, а решение, позволяющее оглянуться назад не более чем на несколько часов (в зависимости от того, сколько времени вы отменили для хранения).

Как и в других случаях, я использую ORM (Propel) с базовым объектом, содержащим настраиваемые методы сохранения и удаления . Эти методы отменяют стандартные операции сохранения и удаления, которые поставляются с ORM. Они проверяют, какие столбцы были изменены, и создают 1 строку в таблице изменений для каждого измененного столбца.

Схема для таблицы изменений : change_pk, user_fk, user_name, session_id, ip_address, method, table_name, row_fk, field_name, field_value, most_recent, date_time

Пример: 1, 4232, 'Gnarls Barkley', 'f2ff3f8822ff23', '234.432.324.694', 'UPDATE', 'User', 4232, 'first_name', 'Gnarles', 'Y', '2009-08-20 10:10 : 10 ';