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