(Postgres 8.3)
I’m working with a DB table X 100+ columns wide (which I can’t change sadly) many of which get updated constantly and very frequently by normal business process.
I have a requirement to update table Y based on updates to a particular column foo in X updated by unusual business process. However, because of the very high number of updates against X simply applying a trigger which inspects X.foo to decide whether to update Y is considered unacceptable.
Table Y is not the end of the line either, there is a chain of ancestors a few deep, all of which need to bubble up to the root.
The only solutions I can think of are:
- breaking X into multiple tables (not allowed to)
- explicitly making the updates to Y (and Z and others) as part of the business logic for updating X but this is going to have a big footprint and leaves a lot of room for somebody getting it wrong or missing it when they have to implement the same in another process. And this is clearly just not good design (which I’m trying to gradually fix where I can).
Does anyone know a way to limit trigger execution by column or any other alternative? Triggers on views? Other voodoo?
You might be able to do something with rules, but has has been previously said, triggers should probably be “good enough”. But if you are trying to solve a management problem rather than a technical one, rules might help you. They’ll apply much earlier during execition. Beware of some pitfalls with them typically with sequences and such.