Re: performance of updates

On Dec 18, 8:06 pm, Tim X <t..._at_nospam.dev.null> wrote:
>
> The only way to really know the right answer is to measure the
> difference.
> Personally, the first thing I'd be asking is whether having a trigger to
> do the insert is actually the right design. Triggers are something which
> are often very useful for specific problems, but too often are used when
> it would be better to do it more explicitly another way - triggers that
> do inserts and updates are possibly the worst in the sense that your
> design is now relying on what could be called side effects - often a
> source of major problems and errors in later maintenance work where the
> people doing the maintenance are no the ones who designed the system and
> may not be as familiar with all these side effects.
>

Sometimes it's even worse than that. I'm passively sitting back and watching a development effort which will be sucking off my production system, done by the vendor of the system. Seems other implementations have issues with this taking 9 hours, so I keep seeing all sorts of stupid ideas flying about - the latest is someone wants to add a trigger that will update date columns added to a bunch of tables. Here's a quote:

"I would keep it very simple, like any activity on the record, even an inquiry, would trigger an update to the field."

Okaaaaaaaayyyyy....

jg

--
@home.com is bogus.
"To our sincere regret, however, it has now emerged that the text
contains deeper levels of meaning, which are not immediately
accessible to a non-native speaker."
http://www.smh.com.au/news/home/technology/eminent-scientific-journal-gets-hit-for-sex/2008/12/11/1228584998876.html