Автообновление столбца даты и времени в SQL Server 2005 - LastUpdated

У меня есть определенная таблица (см. Фрагмент кода ниже). Как я могу добавить ограничение или что-то еще, чтобы столбец LastUpdate автоматически обновлялся при каждом изменении строки?

CREATE TABLE dbo.Profiles
(
        UserName                                varchar(100)            NOT NULL,
        LastUpdate                              datetime                NOT NULL  CONSTRAINT DF_Profiles_LastUpdate DEFAULT (getdate()),
        FullName                                varchar(50)             NOT NULL,
        Birthdate                               smalldatetime           NULL,
        PageSize                                int                     NOT NULL CONSTRAINT DF_Profiles_PageSize DEFAULT ((10)),
        CONSTRAINT PK_Profiles PRIMARY KEY CLUSTERED (UserName ASC),
        CONSTRAINT FK_Profils_Users FOREIGN KEY (UserName) REFERENCES dbo.Users (UserName) ON UPDATE CASCADE ON DELETE CASCADE  
)

database sql-server timestamp sql-update
person Brian Boatright    schedule 30.08.2008    source источник

Ответы (5)


arrow_upward
4
arrow_downward

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

person SQLMenace    schedule 30.08.2008

arrow_upward
24
arrow_downward

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

Просто что-то вроде этого:

CREATE TRIGGER KeepUpdated on Profiles
FOR UPDATE, INSERT AS 
UPDATE dbo.Profiles 
SET LastUpdate = GetDate()
WHERE Username IN (SELECT Username FROM inserted)

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

Учти это...

  • 7 утра - создается пользователь jsmith с фамилией Smithe (упс), LastUpdate по умолчанию 7 утра.

  • 8 утра - "jsmith" отправляет ИТ-специалисту электронное письмо, в котором говорится, что его имя неверно. Вы немедленно выполняете обновление, поэтому теперь фамилия «Смит» и (благодаря триггеру) LastUpdate показывает 8 утра.

  • 14:00. Вашему бездельнику-коллеге наконец-то надоел StumbleUpon, и он проверяет свою электронную почту. Он видит более раннее сообщение от jsmith относительно изменения имени. Он запускает: UPDATE Profiles SET LastName = 'Smith' WHERE Username = 'jsmith' и затем возвращается к просмотру MySpace. Однако триггеру не важно, что фамилия уже была «Смит», поэтому LastUpdate теперь показывает 14:00.

Если вы просто слепо меняете LastUpdate при каждом запуске оператора обновления, это ТЕХНИЧЕСКИ правильно, потому что обновление действительно произошло, но, вероятно, имеет смысл сравнить изменения и действовать соответственно. Таким образом, оператор обновления в 2 часа дня от коллеги по-прежнему будет работать, но LastUpdate по-прежнему будет показывать 8 утра.

- Кевин

person Kevin Fairchild    schedule 30.08.2008

arrow_upward
3
arrow_downward

Я согласен с идеей триггера, хотя я бы использовал соединение для вставки вместо подзапроса. Однако я хочу отметить, что имя пользователя - особенно плохой выбор для первичного ключа. Имена пользователей часто меняются, и когда это необходимо, вам нужно изменить все связанные таблицы. Гораздо лучше иметь идентификатор пользователя в качестве ключа, а затем помещать уникальный индекс для имени пользователя. Затем, когда имя пользователя изменится, вам больше ничего менять не нужно.

person HLGEM    schedule 15.04.2009

arrow_upward
2
arrow_downward

Для этого вам придется использовать триггеры.

person Kibbee    schedule 30.08.2008

arrow_upward
-1
arrow_downward

Я предлагаю создать хранимую процедуру, которая по умолчанию использует lastUpdate как getdate ().

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

Также добавьте это как значение по умолчанию для определения столбца.

person Rob Allen    schedule 30.08.2008
comment
Что-то подобное всегда должно выполняться в триггере. В противном случае это не всегда будет правильно, так как существует множество способов изменить данные без использования sps. Просто потому, что они причиняют боль, это НЕ причина избегать их, если вам нужны точные данные в своей базе данных (которая должна иметь приоритет 1). - person HLGEM; 15.04.2009
comment
Я предполагаю, что Роб Аллен пытался сказать, что он выполняет хранимую процедуру в триггере, где присутствуют вся логика и условные выражения, так что не нужно учитывать потенциальные триггеры, а только SP с очевидной схемой именования, например. spAfterUpdateMyTable - person Lorenz Lo Sauer; 07.12.2013