Каковы общие столбцы аудита для каждой таблицы базы данных?

Question

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

Тогда я видел, что мало кто также добавляет столбцы 'user_created', 'user_updated' в каждую таблицу.

Если я добавлю и эти столбцы тожетогда у меня будет минимум 5 столбцов для каждой таблицы.Это будет слишком много?

Считаете ли вы хорошей идеей иметь эти пять столбцов?

Кроме того, пользователь 'в' user_created 'означает пользователя базы данных?или пользователь приложения?

Answer 1

Я использовал все пять раньше, конечно. Когда я хочу отследить, кто через веб-приложение создает и (последний) редактирует записи, и когда это происходит, я включаю метки времени и зарегистрированного пользователя (но не пользователя БД, это не то, как настроена моя система); мы используем одну учетную запись для всего взаимодействия с БД).

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

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

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

Answer 2

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

Как правило, вы хотите провести аудит пользователя приложения - во многих случаях приложения (такие как Web или SOA) могут подключатьсявсе пользователи с одинаковыми учетными данными, поэтому хранить логин БД бессмысленно.

ИМХО, шаблоны date created / last date updated / lastupdateby никогда не дают полной картины, так как вы сможете только увидеть, кто сделал последнее изменение, и не увидеть, что было изменено.Если вы проводите аудит, я бы посоветовал вам провести полный аудит изменений с использованием таких шаблонов, как аудит триггер .Вы также можете избежать использования триггеров, если ваши вставки / обновления / удаления в ваши таблицы инкапсулированы, например, через Stored Procedures.Правда, таблицы аудита будут очень большими, но, как правило, они не будут подвергаться большим запросам (как правило, только при охоте на ведьм) и могут быть заархивированы, легко разбиты по дате (и могут быть сделаны только для чтения).С отдельной таблицей аудита вам не понадобится столбец DateCreated или LastDateUpdated, так как это можно получить.Тем не менее, как правило, вам все еще понадобится последний пользователь изменений, поскольку SQL не сможет получить пользователя приложения.

Если вы решите логически удалить, я бы не стал использовать «status» в качестве поля, указывающего на логическое удаление., поскольку, скорее всего, у вас есть таблицы, которые моделируют состояние процесса (например, Статус платежа и т. д.). Использование полей bit или char, таких как ActiveYN или IsActive, типично для логического удаления.

Логическое удаление может быть громоздким, поскольку все ваши запросы должны будут отфильтровывать Active=N записей, и, сохраняя удаленные записи в ваших таблицах транзакций, можно сделать эти таблицы больше, чем необходимо, особенно в таблицах Many : Many / junction.На производительность также можно повлиять, так как поле с 2 состояниями вряд ли будет достаточно избирательным, чтобы его можно было использовать в индексах.В этом случае физическое удаление с полным аудитом может иметь смысл.

Answer 3

Простой ответ - внесите в свою базу данных только то, что вам нужно в вашей базе.