Re: Stored procedures returning rowsets

Jaroslaw Nozderko wrote:

>Hi Mark,
>
>
>I think there is also plan/optimize stage between parse and execute...
>And it may be expensive. Another advantage of stored procedures
>is possibility of encapsulating business logic on server side only.
>
>Regards,
>Jarek
>
>Jaroslaw Nozderko
>GSM +48 601131870 / Kapsch (22) 6075013
>jaroslaw(dot)nozderko(at)polkomtel(dot)com(dot)pl
>IT/CCBS/RS - Analyst Programmer
>
Hi Jarek,

Yes, I should have mentioned where plan and optimize fit in, I thinking
about your very point with the comment referring to the "saving of the
parse tree" - I kind of assumed that the plan information was implied
here (but ..er .. yes didnt point it out explicitly)...

Plan and optimize are typically only expensive for complex queries...
and high speed on-line business applications are usually designed use as
simple queries as possible - (optimization issues are part of this
reason). It is quite interesting to examine the TPC A|B|C benchmark full
disclosure reports - there is clearly considerable effort put into
keeping the data access simple.

Your other point - business logic in the server....is very interesting -
I have been thinking about this recently: here goes -

<rant>

1 Vendor Lock In

Every database verdor does server languages differently, so you get
vendor lock in of
your business rules - which inhibits your ability to switch backends.
(like when you get terrible service from your database vender).

2 Business Logic In The Application Server

I remember when folk started putting business logic in the database -
primarily to avoid network calls in client server applications, and to
provide some reusability and limited encapsulation of logic.
These days application servers are the rule, and they are typically
"close" to your database server, so network is not an issue.
Re-usability and encapsulation and usually *much better* supported
within application servers than within database server languages.

</rant>

So I am thinking that the primary reasons for the creation of extensive
database server based languages are no longer applicable today.
However, I am not suggesting the removal of database server languages,
but I think their importance in the scheme of things has diminished.

best wishes

Mark