Зачем нам нужны столбцы аудита в таблицах базы данных? - PullRequest
8 голосов
/ 04 мая 2010

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

  • Создано
  • Создать DateTime
  • Обновлено
  • Дата обновления

С одной точки зрения я вижу таблицы из следующего представления ...

  • Таблицы сущностей:
    • Хороший кандидат на аудит колонки)
  • Справочные таблицы:
    • Аудит столбцов может или не может потребоваться. В некоторых случаях информация о последнем обновлении вообще не требуется, поскольку запись никогда не будет изменена.)
  • Таблицы справочных данных
    • Как и в случае названий стран, состояния объекта и т. Д., Столбцы аудита могут не требоваться, поскольку эта информация создается только во время установки системы и никогда не будет изменена.

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

Я просто хочу знать, потому что мне это кажется нелогичным. Мне трудно понять, почему они так проектируют свою БД? Я не говорю, что они не правы или правы, просто хочу знать, ПОЧЕМУ?

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

Спасибо и всего наилучшего

Ответы [ 4 ]

5 голосов
/ 04 мая 2010

Аудит данных является обязательным внутренним контролем для многих бизнес-систем (причины см. В Sarbanes Oxley). Он должен быть на уровне базы данных, чтобы гарантировать, что все изменения регистрируются, особенно неавторизованные .

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

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

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

2 голосов
/ 05 мая 2010

Эти столбцы предназначены для администраторов баз данных и разработчиков баз данных. Они просто предоставляют быстрый механизм для ответа на такие вопросы, как «Когда эта запись изменилась в последний раз?» "Кто это изменил?" Они недостаточно прочные или мелкозернистые, чтобы соответствовать требованиям SOX, HIPAA и т. Д.

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

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

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

1 голос
/ 04 мая 2010

Многие приложения разрабатываются с использованием некоторого языка ООП, в котором обычно существует класс, такой как BusinessObject , который содержит то, что воспринимается, как правило, полезную информацию, например, такие поля аудита. Не всем сущностям подклассов может понадобиться это, но оно есть, если они делают. Поскольку издержки БД невелики, и вероятность того, что клиент может запросить другую нечетную статистику, основанную на полях аудита, лучше иметь их рядом, чем не иметь их вообще. Если что-то представляет собой статический список информации, такой как названия стран, я вообще не буду помещать это в БД - перечисленные типы данных создаются именно для таких целей.

0 голосов
/ 28 февраля 2014

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

Данные этого типа конфигурации не могут быть обновлены пользователями. Обычно они могут быть размещены и в других местах, таких как свойства, файлы конфигурации или даже жестко запрограммированные константы. Конечно, размещение данных конфигурации в этих местах может быть плохим дизайном или стилем, но с точки зрения аудита, имеют ли они значение? Кроме того, если эти данные могут обновляться пользователями, то единственными, кто может обновить их, являются либо dba, либо хакеры. По-настоящему злобные администраторы базы данных или хакеры уже знают законы, прежде чем нарушать законы, и они находят способы обойти законы.

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

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