Дата последнего обновления: Antipattern? - PullRequest
4 голосов
/ 08 января 2009

Я постоянно вижу, как всплывают вопросы, ссылающиеся на столбец в таблице базы данных с именем что-то вроде DateLastUpdated. Я не понимаю.

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

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

Это, конечно, даже близко не похоже на контрольный журнал; так что это не может быть оправданием. И если равно и контрольный журнал где-то в журнале или где-либо еще, это поле будет избыточным.

Чего мне не хватает? Почему этот шаблон так популярен?

Ответы [ 6 ]

7 голосов
/ 08 января 2009

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

2 голосов
/ 08 января 2009

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

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

1 голос
/ 08 января 2009

Такие вещи обычно используются для бизнес-приложений, где для запуска обновления требуются действия пользователя. Как правило, это будет какое-то бизнес-приложение (например, настольное приложение CRM), и для большинства обновлений, как правило, существует только один способ сделать обновление.

Если вы просматриваете адресные данные, это было сделано через экран «Ведение адреса» и т. Д.

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

Сотрудники колл-центра, как правило, также имеют какие-либо функции «Заметки» или «Журнал», в которых они могут вводить текст произвольной формы, чтобы узнать, почему звонил клиент, и какие действия были предприняты, чтобы следующий оператор мог узнать, где он остановился, клиент перезванивает.

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

0 голосов
/ 21 января 2009

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

0 голосов
/ 08 января 2009

есть пара сценариев

Допустим, у вас есть таблица адресов для ваших клиентов у вас есть приложение CRM, клиент звонит, что его адрес изменился месяц назад, в столбце LastUpdate видно, что эта строка для этого клиента не была затронута в течение 4 месяцев

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

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

есть 2 сервера БД, сравнивая столбец даты, вы можете узнать, были ли все изменения реплицированы или нет и т. Д. И т. Д.

0 голосов
/ 08 января 2009

Это, безусловно, популярно - например, у rails есть сокращение для него, а также метка времени создания (: timestamps).

На уровне приложения это очень полезно, так как тот же шаблон очень распространен в представлениях - посмотрите на вопросы здесь, например (ответ 56 секунд назад и т. Д.).

Он также может использоваться ретроспективно в отчетах для генерации статистики (например, какова кривая роста количества записей в БД).

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