Вопрос по database – Идеи по разработке базы данных для сбора контрольных журналов [закрыто]

41

Как я могу вести журнал данных в моей БД?

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

Как я могу вести такой журнал?

Ваш Ответ

5   ответов
24

Основная идея заключается в том, что вы никогда не обновляете и не удаляете данные.

Каждая таблица имеет 2 столбца даты и времениfrom а такжеto.

Они начинаются со значения NULL в каждом (начало времени до конца времени)

Когда вам нужно «изменить» строка, в которую вы добавляете новую строку, в то же время вы обновляетеto в предыдущем ряду к Сейчас иfrom в строке, которую вы добавляете в сейчас.

Вы считываете данные из таблицы через представление, в котором есть где to = null.

Этот метод также дает вам представление о состоянии вашей базы данных в любой момент времени.

EDIT

Просто чтобы уточнить в ответ на комментарий: Последовательность будет дана первичным ключом таблицы, который будет номером автоинкремента.

Я использовал этот шаблон ранее для конкретных таблиц. Я бы порекомендовал иметь уникальный индекс, состоящий из внешнего ключа (ключей) и тегов "to". значение. Это означает, что вы не можете вставить другую строку, прежде чем обновите поле до предыдущей текущей записи.
Если вам нужны данные, которые вы делаете, если вам нужен контрольный журнал, они не теряются.
Я бы не стал использовать столбцы даты и времени для каких-либо данных ID / поиска или данных последовательности. Системная дата может измениться по любой причине, или возможны несколько операций, происходящих в одном и том же временном разрешении одного значения даты / времени. Если вам нужно захватить последовательность во времени, используйте временную метку (гарантированно уникальную), или длинные целые числа, или используйте направляющие, поскольку ваша цепочка слишком строит цепочку (но вы теряете время как элемент информации - также прочитайте ответ ниже ...)
Колтен, если вы работали в отрасли, где все следовало отслеживать из-за соответствия нормативным требованиям, вы понимаете, что это неизбежное зло. Кроме того, автор может проверять только те подмножества таблиц, которые его больше всего интересуют, поэтому нехватка места связана с уровнем ведения журнала, который он / она хочет ...
Разве это не просто огромная трата пространства?
13

вставлять только & quot; базы данных, как описано Ширазом Бхаджи, но вы можете использовать более простую технику. Для каждой таблицы, для которой нужно вести данные аудита, просто добавьте дополнительный столбец для «Обновленное время», по умолчанию используется по умолчанию. Когда вы вносите изменения в запись, а не обновляете ее, просто вставьте все свои данные; столбец updatedTime получит текущее время.

Обратите внимание, что этот метод означает, что вы должны нарушить или пересмотреть свои УНИКАЛЬНЫЕ ограничения; Вы можете сохранить первичный ключ, но уникальность становится составной частью вашего первичного ключа и вашего обновленного времени.

Преимущество этого метода заключается в предоставлении вам известного диапазона исторических данных для каждой записи в таблице (каждая запись действительна в течение заданного времени, если она является ТОП-1 записей WHERE TimeOfInterest & gt; updatedTime ORDER BY updatedTime DESC) с низким накладные расходы (только один столбец в таблице). Он также вполне поддается преобразованию из таблиц, не использующих этот метод, с помощью простой команды ALTER TABLE для добавления одного столбца (который вы можете называть последовательно). Затем вам просто нужно изменить свои УНИКАЛЬНЫЕ ограничения, чтобы использовать совокупность их текущих ограничений и столбца UpdatedTime, и некоторые запросы необходимо будет изменить.

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

5

зуете это для создания самой последней версии ваших данных. Вы создаете & quot; контрольные точки & quot; периодически или используя кэширование, чтобы ускорить это.

Есть презентация о ком-то, кто использует эту технику:http://www.infoq.com/presentations/greg-young-unshackle-qcon08, Большим преимуществом здесь является то, что, поскольку у вас есть только журнал аудита, вы будете совершенно уверены, что ваш журнал аудита верен.

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

17

[Late post but it adds two techniques not already mentioned here]

Reading transaction log & # X2013; если ваша база данных находится в режиме полного восстановления, то в журнале транзакций хранится много полезной информации, которую можно использовать для просмотра истории каждой строки. Недостатком является то, что это не поддерживается по умолчанию. Вы можете попробовать использовать недокументированные функции DBCC LOG или fn_dblog или сторонний инструмент, такой какApexSQL Log

Using Change Data Capture - Изменить сбор данных по сути, делает то же самое, что показано выше, но это более упорядочено и немного проще в использовании. К сожалению, это доступно только в корпоративной версии.

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

1

содержит ли мой ответ на другой вопрос журнала базы данных нужную вам информацию. Найдите это здесь ...

Таблицы истории плюсы, минусы и ошибки - с помощью триггеров, sproc или на уровне приложения

Похожие вопросы