alen teplitsky (10/14/2010)
i think that if you're adding triggers to try to keep track of every single change you have problems, security problems. it's a huge performance hit to have triggers on every table and for those of us with databases on SAN's it's a lot of money for the extra storage.if you have people making changes they shouldn't be then you need to go to management to make security changes. we used to be all SQL logins and people would always share passwords so there was no control. we've changed to mostly windows authentication now and it's a lot easier to control things
It all depence from the level of the changes and the data you need to have in real time. For example, if you need only demographic data like address, phone, and email to be real time then it will be resonable to do such a process. And if you need many tables then this approach may not work. If the rate of changes is low it may works for the big databases. If the rate of changes if extenceve then it may not work at all. This article shows one of the methodologies. And if it used wrong way it will create harm as anything else. Whith non properly defined indexes performance can be killed. But no one complaining that indexes are bad idea or will not be working. As always, you need to do impact analysis and understand what and how to use.