I seem to remember reading an artical about this years ago.
Apparently there was some 'discussion' inside the Interbase company
when Borland bought it, about the usefulness of SP (and I assume
triggers too). I got the impression the people at Interbase saw no
advantage in it, but were forced by Borland.

Their argument was that there was no speed advantage - over embedded
SQL. Borland finally 'talked them round' by arguing it wasn't about
speed, but encapsulation. (I got the impression a phrase like 'do it
or else...' was also involved!!)

I have really mixed feelings about the whole 'embedding code on the
db server' issue. It has lots of advantages of course (speed could be
one). But I feel the proper place for business logic is in the
application layer, the database should just store data, do joins,
manage transactions etc.

Why? well the best reason is that your fb server is a precious
resource. You can do busines logic anywhere (multi app servers) but
unless you go down the replication route, you've only got 1 database!
And when you start embedding code, it's easy to drift into putting
business logic in there too.

That said, I do use SP's and triggers all the time. I just try to
avoid complex business logic...

John

--- In firebird-support@yahoogroups.com, "Alfred Thomas"
<alfred@f...> wrote:

> Hi
>
> I have a question, which I hope is not too off-topic.
> We are designing a system and have to decide whether to add as much

of the

> code as possible as stored procedures. Or should we stay away from

stored

> procedures as much as possible. I am very much pro SP. Can anyone

tell me if

> there is a study/white paper/faq/whatever that explains why or why

not to

> take either of the approaches.
>
> Regards
> Alfred Thomas