a lot of bussines logic is implemented in db. splitting it into several triggers rather then using single one helps in
codemanagement. just fyi.
with regards
MK
25. 11. 2012 v 11:31, "Guillaume Lelarge" <guillaume@lelarge.info>:
> On Wed, 2012-10-24 at 13:48 +0200, Michal Kozusznik wrote:
>> Hello
>> Have you considered to split triggers into branches?
>> I can imagine:
>>
>> * triggers
>> o insert
>> + before
>> + after
>> o update
>> + before
>> + after
>> o before
>> + before
>> + after
>>
>> Triggers which are set for multiple events would appear in all
>> particular branches.
>
> That's probably the biggest issue with your proposal. Objects shouldn't
> appear at different locations (yeah, we already do this with the
> language objects in 9.1, but I'm not sure how we should deal with that).
>
>> Of course it might be optional for some who don't like it.
>>
>> We have a lot of triggers for single tables (50) and would be helpful to
>> us to organize them in some way.
>>
>
> 50 triggers on a single table? wow, something is so wrong with your
> setup. I don't quite get why you would end up with so much triggers.
> Isn't that a big issue with performances?
>
> But I get it that with such a setup, you need a better tree.
> Unfortunately, your kind of setup is probably really specific, and isn't
> a usual one.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>