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

18

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

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

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

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

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

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

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

Gaz_Edge
источник
2
Я думаю, что вы уже ответили на вопрос самостоятельно. Единственный ответ, который можно дать: «Это зависит от сценария».
Филипп
3
На практике у меня есть временные метки почти на каждой таблице (в основном по указанным вами причинам). Насколько я могу сказать, это не оказывает негативного влияния на производительность, по крайней мере, для тех типов баз данных, которые обычно используются в веб-разработке с, возможно, около 30 000 статей и сотнями тысяч заказов (которые в любом случае требуют временных отметок). Могут быть крайние случаи, но, например, наша система ERP (Microsoft Navision) также использует эти временные метки на большинстве таблиц.
Торстен Мюллер
2
Вы говорите, что предоставление каждой таблице метки времени, безусловно, является отличным способом быстрого перемещения по базе данных , но вы не говорите, почему. Почти в каждой СУБД временная метка является очень небольшим значением - обычно 8 байтов или меньше. Если вы не добавите индексы, это незначительно.
Росс Паттерсон
Обновление меток времени, потому что меняются запахи. Это будет означать, что у вас будет только время самого последнего изменения в записи, а в бизнесе вам нужна история всех изменений.
Питер Б
@PieterB Определенно важно сохранять историю для некоторых таблиц, но я никогда не сталкивался с случаем, когда вы хотели бы сделать это для каждой таблицы - YMMV.
Робби Ди

Ответы:

5

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

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

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

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

Леон Алексис Кардинал
источник
15

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

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

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

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

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

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

Робби Ди
источник
6

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

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

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

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

JeffO
источник
+1 Это тоже распространенный метод, который можно использовать с помощью триггеров таблицы, чтобы выбросить запись в таблицу истории, которая затем может быть дельта-обработкой. Некоторые СУБД (например, функция Oracle Flashback) также поддерживают использование запросов на определенный момент времени, когда можно проверить состояние данных в некоторый момент в прошлом.
Робби Ди
простое решение было бы сохранить любой запрос, который обновляет и таблицы в журнал?
Gaz_Edge
Это еще один способ, хотя он может стать громоздким для таблиц с большим объемом / частотой обновлений. Хотя создание внешнего стола может предотвратить некоторые проблемы ...
Робби Ди,
1

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

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

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

DougM
источник
0

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

Я не вижу значения в 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вы хотите. Таким образом, вы не только сохраняете каждую дату изменения - не только последнюю - но также сохраняете каждую версию этого документа. Единственный аргумент против этого на самом деле - это место на жестком диске, но, конечно, когда вы дойдете до того момента, когда вам будет интересно, какое место на жестком диске он использует, - в большинстве случаев вы будете еще более обеспокоены версионированием данных.

Алджи Тейлор
источник