Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Summary
In this article, you’ve learned the necessary steps to track date/time of changes made to the back-end SQL database used by your web application. These changes could be tracked by the logic built into the web application, but it’s far more reliable to use the SQL triggers to detect them.
Changes to individual rows (INSERT and UPDATE operations) can be logged in a date/time field in the same row. Deletions must be tracked in a separate table (the Timestamps table in our application). This table can also be used to track INSERT and UPDATE operations for tables that change very rarely.
The actual date/time of last modification almost always has to be combined from various sources in your SQL database. While you might do that calculation in the web page (using SQL SELECT statements), it’s better to offload the process to a stored SQL procedure; the end result of the calculation is always a single date/time field, but the steps needed to get it might involve numerous SQL queries.
Don’t forget that this article gives you just the last part of the whole picture. The Last-Modified date/time computed in the SQL database has to be combined with other modification parameters covered in part 1) or control the caching behavior of intermediate caches and the end user’s browser with the ETag and the Cache-Control HTTP headers.