Когда таблица базы данных должна использовать временные метки?

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

Мне было интересно, когда в таблицу базы данных должны быть добавлены созданная и обновленная отметка времени?

Первый очевидный ответ заключается в том, что если какой-либо бизнес-логике необходимо знать, когда что-то было обновлено (например, дата завершения транзакции и т. Д.), То оно должно войти.

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

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

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

Так когда же таблица базы данных должна использовать метки времени создания и обновления?

Для лучшего и более полного управления базой данных и наиболее мудрой практикой является сделать это.

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

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

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

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

Проще говоря:

Для любой таблицы, где записи добавляются (но никогда не обновляются), например, логины и т. Д., Я бы подумал о добавлении столбца DATE_CREATED.

Для любой таблицы, где записи добавляются и обновляются, я бы рассмотрел добавление столбца DATE_CREATED и DATE_UPDATED.

Я работал во многих местах, где DATE_CREATED и DATE_UPDATED включены в каждую таблицу по умолчанию как часть дизайна.

Для более крупных баз данных с миллионами / миллиардами строк, в которых обновление баз выполнялось в течение нескольких дней, мы также добавили столбец SOURCE для некоторых таблиц, в которых указывалось, какой банк данных вызвал обновление, например, сторонний канал, обновление пользователя, модификация DBA, очистка данных и т. д.

То, как сформулирован вопрос, вы запрашиваете список вещей. Я рискну не отвечать прямо на ваш вопрос, а отвечать, когда вам следует использовать альтернативное решение.

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

Было бы более полезно иметь журнал всех обновлений для данной записи? Просто зная последнее обновление, может не хватить информации. Этот журнал может быть помещен в отдельную таблицу. Было бы удобнее отслеживать изменения из нескольких таблиц в одном и том же файле журнала (это не обязательно должна быть таблица). Это предотвращает массовый запрос объединения всех таблиц change_dates для получения агрегатов. Это также поможет устранить неполадки, помогая вам увидеть записи других событий в вашей системе.

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

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

1. Таблица представляет собой основную запись некоторой активности, предоставленной пользователем. Если пользователь выполняет X, и у вас есть и a, Table_Xи a, Table_Yкоторые являются потомками «один ко многим» Table_X, Table_Yэто не первичная запись и поэтому не требует дополнительных полей.
2. Если у вас есть постоянная, временная или периодическая потребность в отслеживании системы . Если вам нужно проверить, что Table_Yобновляется только при Table_Xобновлении, дополнительные поля отслеживания могут помочь.

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

Личное мнение:

Я не вижу значения в modifiedстолбце.

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

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

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

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