SQL - Дизайн таблиц - столбцы DateCreated и DateUpdated
Для моего приложения есть несколько классов сущностей: User, Customer, Post и т. д.
Я собираюсь разработать базу данных и хочу сохранить дату создания и обновления сущностей. Вот тут-то и сложно. Конечно, можно добавить столбцы created_timestamp и update_timestamp для каждой из таблиц сущностей, но это не лишний раз?
Другой возможностью может быть создание таблицы журнала, в которой хранится эта информация, и она может содержать отслеживание обновлений для объекта Любые.
Какие-нибудь мысли? Я рассчитываю на реализацию последнего.
Ответы 5
Как часто вам нужно будет включать созданные / обновленные временные метки в слой презентации? Если ответ будет чем-то большим, чем «раз в долгое время», я думаю, вам будет лучше, если эти столбцы будут в каждой таблице.
Я делаю последнее, с таблицей «журнала» или «событий». По моему опыту, «обновленная» временная метка довольно быстро разочаровывает, потому что большую часть времени вы обнаруживаете исправление, в котором вам нужно не только самое последнее время обновления.
В проекте, над которым я работал пару лет назад, мы реализовали триггеры, которые обновляли то, что мы называли таблицей аудита (в ней хранилась основная информация о вносимых изменениях, по одной таблице аудита на таблицу). Это включало дату изменения (и последнее изменение).
Они применялись только к ключевым таблицам (а не к таблицам объединений или справочных данных).
Это устранило многие обычные неудобства, связанные с необходимостью учитывать поля LastCreated и LastModified, но добавило неудобств, связанных с поддержанием триггеров в актуальном состоянии.
В конце концов, дизайн таблицы триггеров / аудита работал хорошо, и все, что нам нужно было запомнить, - это удалить и повторно применить триггеры до ETL (!).
Подход с единой таблицей для всех таблиц имеет две основные проблемы, о которых я могу думать:
- Дизайн таблицы журнала (вероятно) будет ограничивать дизайн всех других таблиц. Скорее всего, в таблице журнала будет один столбец с именем TableName, а затем другой столбец с именем PKValue (в котором будет храниться значение первичного ключа для записи, которую вы регистрируете). Если некоторые из ваших таблиц имеют составные первичные ключи (то есть более одного столбца), тогда дизайн вашей таблицы журнала должен будет учитывать это (возможно, с помощью таких столбцов, как PKValue1, PKValue2 и т. д.).
- Если это какое-то веб-приложение, то удостоверение пользователя, которое будет доступно из триггера, будет учетной записью приложения, а не идентификатором пользователя веб-приложения (который, скорее всего, вы действительно хотите сохранить в своем CreatedBy. поле). Это только поможет вам различать записи, созданные кодом вашего веб-приложения, и записи, созданные иначе.
Столбцы CreatedDate и ModifiedDate не являются избыточными только потому, что они определены в каждой таблице. Я бы придерживался этого подхода и поместил триггеры вставки и обновления в каждую таблицу для заполнения этих столбцов. Если бы мне также нужно было записать конечного пользователя, который внес изменение, я бы пропустил триггеры и заполнил поля отметки времени и пользователя из моего кода приложения.
Это для веб-CMS, над которой я работаю. Дата создания и даты последнего обновления будут отображаться на большинстве страниц, а также будут отображаться списки для последних созданных (и обновленных) страниц. Интерфейс администратора также будет использовать эту информацию.