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

Question

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

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

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

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

Answer 1

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

<Ол>

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

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

Столбцы

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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