SQL - Дизайн таблицы - столбцы DateCreated и DateUpdated

Question

Для моего приложения есть несколько классов сущностей: Пользователь, Клиент, Почта и т. Д.

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

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

Есть мысли? Я полагаюсь на реализацию последнего.

Answer 1

Подход «единый журнал для всех таблиц» имеет две основные проблемы, о которых я могу подумать:

1. Дизайн таблицы журнала (вероятно) будет ограничивать дизайн всех других таблиц. Скорее всего, в таблице журнала будет один столбец с именем TableName, а затем другой столбец с именем PKValue (в котором будет храниться значение первичного ключа для записи, которую вы регистрируете). Если некоторые из ваших таблиц имеют составные первичные ключи (то есть более одного столбца), то дизайн таблицы журналов должен учитывать это (возможно, с помощью таких столбцов, как PKValue1, PKValue2 и т.
2. Если это какое-то веб-приложение, то идентификатором пользователя, который будет доступен из триггера, будет учетная запись приложения, а не идентификатор пользователя веб-приложения (который, скорее всего, вы действительно хотите сохранить). в вашем поле CreatedBy). Это только поможет вам отличить записи, созданные кодом вашего веб-приложения, от записей, созданных в противном случае.

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

Answer 2

Я делаю последнее с таблицей «log» или «events». По моему опыту, «обновленная» временная метка становится довольно быстро разочаровывающей, потому что большую часть времени вы оказываетесь в исправлении, в котором требуется не только самое последнее время обновления.

Answer 3

Это для веб-CMS, над которой я работаю. Даты создания и последнего обновления будут отображаться на большинстве страниц, и будут списки для последних созданных (и обновленных) страниц. Интерфейс администратора также будет использовать эту информацию.

Answer 4

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

Они были применены только к таблицам ключей (не к объединениям или таблицам справочных данных).

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

В конце концов дизайн таблицы триггеров / аудитов сработал хорошо, и все, что нам нужно было запомнить, это удалить и повторно применить триггеры до ETL (!).

Answer 5

Как часто вам нужно будет включать созданные / обновленные метки времени в слой презентации? Если ответ будет чем-то большим, чем «один раз в прекрасное время», я думаю, вам будет лучше обслужить эти столбцы в каждой таблице.