One of the questions that came up during a panel discussion at SQLSaturday #4 was whether it was better to have one trigger or many. It's a Zen question, no real right answer as far as I'm concerned. In practice having 7 update triggers is probably not a good idea, both from a raw performance perspective as well as just being able to easily see what is going on. I like having separate triggers for insert, update, delete, though I sometimes combine them for basic auditing. I also like adding an additional trigger when I'm adding functionality that probalbly won't be permanent, when I'm done I can just drop the trigger with no danger I've made an incorrect edit to the existing trigger.

Another question was about auditing within triggers and making sure they get a true picture of the original state of the data. The deleted table holds the 'before' image of the data and that stays static for the life of the trigger. It doesn't matter if you read from it as the first line of the trigger or the last, it's still the before image.

The last question was about logging changes in column format, showing before/after value along with the column name. Totally valid and possibly lighter than my standard approach of just preserving a copy of the entire row. The only thing I'd argue for is a standard implementation so you don't get a mish mash that makes trying to use/report on the auditing data painful.