Стандарты именования объектов базы данных

Часть IV: создатьUdt и изменитьUdt

В Части III этой серии я рассказал об именовании ключевых столбцов. На этот раз я обращаю внимание на два поля, которые действительно должны быть в каждой таблице: при попытке отследить проблемы в базе данных очень полезно знать дату и время, когда данные были впервые созданы, и когда они были наиболее недавно модифицированный. В рамках стандартизированного подхода к проектированию баз данных у меня появилась привычка добавлять два столбца в каждое определение таблицы; createUdt и modifyUdt, которые предоставляют эту возможность.

Что в имени? Если вы читали статью о стандартах именования столбцов, вы узнаете базовое имя udt. Это означает, что столбец отражает время UTC, а не местное время. Это намек на интернационализацию, которую, я думаю, следует учитывать в каждом приложении, особенно на ранних стадиях проектирования и реализации. Префиксы create и modify не требуют пояснений и, конечно же, необходимы для того, чтобы различать два типа дат в заданном определении таблицы. Наконец, две даты имеют одинаковый статус и значение, и поэтому обе они имеют префиксы.

NULL и DEFAULT Столбцы createUdt и modifyUdt должны быть указаны как NOT NULL, потому что они всегда должны быть заполнены. Кроме того, предполагая, что ваша конкретная реляционная база данных имеет функцию даты UTC (большинство из них), по умолчанию для createUdt и modifyUdt следует указать использовать функцию UTC, чтобы они получали правильную дату и время при создании записи.

Соблюдайте их правильно Если эти столбцы будут полезны, ваше приложение никогда не должно напрямую манипулировать ими. Чтобы они были полезными, вы должны иметь абсолютную веру в то, что они действительно отражают дату и время создания или модификации, а не чью-то интерпретацию этих фактов. Для этого я использую триггер (древний код SQL Server 2005 показан ниже только для иллюстрации — ваш код вполне может отличаться), который автоматически исправляет эти значения в случае их непосредственного изменения. каким-то образом. В любом случае это немного отличается; createUdt возвращается к исходному значению, тогда как modifyUdt всегда устанавливается на текущую системную дату и время.

CREATE TRIGGER
  DogTrg
ON
  Dog
FOR
  UPDATE
AS
BEGIN
  UPDATE
    Dog
  SET
    Dog.modifyUdt = GETUTCDATE()
  FROM
    Dog AS Dog INNER JOIN
    INSERTED AS INSERTED ON INSERTED.uid = Dog.uid
  UPDATE
    Dog
  SET
    Dog.createUdt = DELETED.createUdt
  FROM
    Dog AS Dog INNER JOIN
    DELETED AS DELETED ON DELETED.uid = Dog.uid
  WHERE
    Dog.createUdt != DELETED.createUdt
END

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

Меня всегда удивляло, что поставщики баз данных не включают эти возможности прямо из коробки — я помню, как использовали базы данных в туманных и далеких странах, где эти данные были доступны в качестве стандартной функции для каждого определения таблицы. Черт возьми, может быть, современные базы данных и делают это, просто я еще не нашел эту функцию. Большое спасибо за чтение, и дайте мне знать, что вы думаете.

© 2019 Intellog Inc.

Эта серия статей была первоначально опубликована Теренсом С. Гэнноном в 2007 году в первоначальной версииблога Intellog. Поскольку мы приступаем к разработке новой базы данных с чистым листом для нового клиента, мы решили вернуться к этим исходным документам, чтобы проверить, выдержали ли они испытание временем. По большей части они есть, но мы также воспользовались возможностью немного обновить их для более современной эпохи. Мы хотели бы услышать ваши отзывы.