Having thought about it a little more, I would say the only
ligitimate reason for sproc / trigger code is to compensate for
deficiencies in the declaritive language. In the same way triggers
were used in Oracle 5, 10-15 years ago, to maintain foreign keys.
When your declaritive language is sufficiently advanced to cope, the
need for embedded code on the server for non-business logic
disappears.

Not to say that FB hasn't 'got there' yet in terms of sophisiticated
SQL, just the startard itself has some way to go. In 10-20 years,
who knows!

John


--- In firebird-support@yahoogroups.com, "johnsparrowuk"
<jsparrow@e...> wrote:

> 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