A few weeks ago I did some consulting work for a client who had a poor-performing SQL Server. From my title and first sentence, you know where this is going...

My client was in the process of migrating to a new application. Since they were migrating in stages, they needed to run both old and new applications concurrently. However, they wanted the data to stay in sync, so they used triggers to duplicate transactions between tables. As you can imagine, they had all kinds of locking, blocking and deadlock issues. So we created indexed views of all of the new tables mapping the old columns to the new. Now the old application was using the new structure and all of their data was in one place.

The point here isn't that we shouldn't use triggers. Triggers have their place. In fact, I’ve seen some really cool things done with triggers, cool things that didn’t crush servers. Having said that, I rarely use them because I usually can do what I need to do with a view or a proc.