Должен ли я хранить информацию журнала в основной таблице базы данных?

Question

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

Спасибо.

Answer 1

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

Answer 2

Обычно я буду хранить информацию о столбцах LastChangeUser и LastChangeDate в каждой таблице, а иногда включать также CreateUser и CreateDate. Что обычно хорошо для большинства столов.

Однако, если вам нужно хранить больше, для действительно важных таблиц (обычно связанных с деньгами) перейдите к другой таблице. В этой таблице (OriginalTableName_History) у меня обычно есть HistoryID, который является автоинкрементом, HistoryDate и HistoryType (I = insert, U = update, D = delete), а затем все столбцы из исходной таблицы. У меня обычно будет один триггер на главной таблице, который помещает каждое изменение (вставка / обновление / удаление) в таблицу истории.

Answer 3

Вы всегда должны отделять свою оперативную базу данных (текущую информацию о продуктах, клиентах и ​​т. Д.) От хранилища журналов. В зависимости от случая, я также предлагаю вам создать базу данных «история» и хранить там все устаревшие данные, чтобы не перегружать рабочую базу данных. Выполнение выбора в огромных базах данных всегда происходит медленно, поэтому вы должны уменьшить его размер любыми возможными способами и создать индексы для повышения производительности. Информация о регистрации должна храниться в другой базе данных. Поля наподобие «Last Modified By» я не рассматриваю как информацию для регистрации, вы можете иметь их в любой таблице. Я также предлагаю вам не иметь слишком много внешних ключей в оперативной базе данных (хранить информацию журнала без прямой ссылки на оперативные данные), потому что это также замедляет управление данными.

Надеюсь, это поможет.

Answer 4

Короче говоря, было бы лучше иметь в отдельной таблице.

Answer 5

Если вашему приложению нужно только знать, каковы текущие атрибуты продукта, целесообразно поместить информацию аудита в другую таблицу, поскольку она упрощает запросы и повышает производительность.

С другой стороны, если вам нужночтобы иметь возможность реконструировать объекты в определенные моменты времени (например, если ваше приложение обычно должно иметь возможность ответить на вопрос «Под каким брендом мы продавали этот продукт в 2004 году?»), вы должны никогда не изменять записи : изменения в объекте являются частью данных объекта и должны быть в одной таблице.(См. Статью Мартина Фаулера « Шаблоны для вещей, которые меняются со временем » для хорошего обсуждения этого в объектно-ориентированном контексте.)

Answer 6

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

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

Answer 7

Это зависит от вашего приложения и объема сохраняемой информации. Некоторые фреймворки, такие как Ruby on Rails, могут автоматически обновлять поля, такие как созданный_байем, поэтому, если вы обладаете такой гибкостью и нуждаетесь только в нескольких полях, вам может быть проще просто сохранить его в одной таблице.

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

Answer 8

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

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