Question

Table: Customer with columns Start_Time and End_Time.

I need to add a new column “Duration” that is End_Time – Start_Time.
However, I need to do this using a trigger or procedure so that immediately after a new record is added to Customer table, the column Duration is updated.

Answer 1

If you are using MS SQL, the ideal answer is probably a computed column.

The less data you actually duplicate, the less opportunity for data inconsistency you will have, therefore the less consistency-ensuring/verification code and fewer maintenance processes will result from your schema.

To set this up, (again, if using MS SQL), just add another column using the designer, and expand the “Computed Column Specification” area. (You can refer to other columns from this same table for this calculation.) Then enter “End_Time – Start_Time”. Depending on what you are going to do with this data, may want to use something like DATEDIFF(minute, Start_Time, End_Time) for your formula, instead. It’s exactly what this feature is for.

If it is a very expensive calculation (which yours is probably not, from the information you’ve given) you could configure the results to be “persisted” – that’s very much like a trigger but clearer to implement and maintain.

Alternately, you could create a new View that does the same calculation, and “project” this first table through it whenever getting information. But you probably already knew that, thus this answer was born! 🙂

p.s. I personally recommend avoiding triggers like the plague. They cause extra operations that are often not expected by a developer, maintainer, or admin. This can cause operations to fail, return unexpected extra result sets, or modify rows that perhaps an admin was specifically trying to avoid modifying during an administrative (read: unsupported grin) fix.

p.p.s. In this case I’d also recommend against a stored procedure, for the same maintenance reason as triggers. Although you could restrict security such that the only way to update the table was through a stored procedure, this can fail for many of the same reasons triggers can fail. Best to avoid duplicating the data if you can.

p.p.p.s 🙂 This is not to say stored procedures are bad as a whole. On complex transactional operations or tightly integrated procedural filtering of large related tables in order to return a comparatively small result set they are still often the best choice.