--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 01:33 11/09/2008, unordained wrote:
>
> >2. Doesn't matter; triggers and stored procedures have the same

byte limit on the amount of code you can stuff into them;

>
> Not true. There is a 48KB limit on the total BLR size of each PSQL

module (trigger or SP). Breaking large modules into smaller ones not
only avoids this limit but makes maintaining PSQL suites cleaner,
easier to test and less prone to undetected logic errors (just as with
any programming system!)

>
> >creating a separate SP just polutes the database namespace, which

is already too easy to do;

>
> Pollution is in the eye of the beholder, methinks. My modularised

code is pollution to you. Your monolithic program is a horror to me
and anyone else who has to maintain your code. As to namespaces, a
functional object naming system should be an explicit objective of any
database design. We all have the choice of clean or dirty in this
respect! ;-)

>
> There is a down-side to modularising PSQL, though, which will

particularly bite a developer whose instincts are not attuned to
modularity. If you change the inputs or outputs of a "downstream"
module, you'll have to recompile the upstream modules, since they are
wired to the old inputs. So it's not usually a good practice to
extend the layers to great depths of dependency. Often it works best
to have a "top-level" module whose job is to control the call stream
and do the final actions. And ALWAYS to document!

>
> >an extra procedure call seems unlikely to speed things up.
>
> It won't. But it won't slow it down, either.
>
> >It wouldn't change your concurrency situation at all.
>
> This is true. This design needs a big re-think, as you correctly

pointed out.

>
> ./heLen

Thank you Helen for pointing out the diferences and confirming the
needed re-think I have to do on my design.

Thanks for your time.
Andrew