The whole point of n-tier distributed programming is to keep business logic outside of
the database layer.
Stored Procedures do have performance benefits, but it's much better from a design
perspective to keep all logic in the middle layer and leave the database as a dumb
persistence layer.
Some would say that it's better to incorporate all the logic in the data layer and so
multiple applications can call it without need to reduplicate code. But the same thing
can be said of having the logic reside in the middle layer, where you also have the
benefits of a strong OO machine independent language.
- Brian Chan ([EMAIL PROTECTED])
-----Original Message-----
From: Frank Eggink <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Subject: RE: Stored procedures and J2EE
Date: Sat Sep 08 08:07:53 GMT 2001
Is it correct to state that from a performance and design perspective using stored
procedures is helpfull if you need
access from outside the J2EE environment?
If no out side access is necessary, the stored procedures are likely to be helpfull
for perfomance if they filter out a
lot of data or when you are using recursive logic (this way you are reducing the
overhead of the remote calls), or am
I missing a point with respect to performance differences between Stored Procedures
and plain old SQL?
Further more I realize now Stored Procedures are an interesting option in case of
severe security requirements. You
can differentiate access constraints to the Stored Procedures and minimise the amount
off people / systems that
have full access to you system.
FE
On Thursday, September 06, 2001 8:08 PM, Juan Lorandi (Chile)
[SMTP:[EMAIL PROTECTED]] wrote:
> I (empirically) reached the same conclusion; but instead of dropping CMP, we
> provided performance improvements ON TOP of the EJB's (VO's and VO caches).
> Thank god we did it this way, because the DB can't scale as easily as the
> app-server cluster.
>
> My 2c,
>
> JP
>
> -----Original Message-----
> From: Rian Schmidt [mailto:[EMAIL PROTECTED]]
> Sent: Jueves, 06 de Septiembre de 2001 12:51
> To: Orion-Interest
> Subject: Re: Stored procedures and J2EE
>
>
> I'm interested as to how you can say this... we just did a series of tests
> here to see what the effect of pulling out some fairly complex stored
> procedures into CMP beans, and the performance impact was enormous. We've
> actually gone the other way, that is, developing stored procedures for each
> anticipated database. The fallback is that the logic is done in the beans,
> but that is a worst-case scenario. Now, I realize that this would be
> considered such bad form in a Sun-controlled world of pure J2EE that I
> hesitate to even mention it... but in the real world, any significant hit on
> performance is enough to convince us to denormalize a bit, so to speak.
>
> I don't think that you can say "there's absolutely no hit on performance"
> not to use stored procedures, particularly if that procedure requires
> repeated queries of the data in a pseudo-recursive way. Do you really think
> that any performance hit that we've seen is a result of poor design? I'm
> really interested in your reasoning.
>
> Rian
>
> ----- Original Message -----
> From: The <mailto:[EMAIL PROTECTED]> elephantwalker
> To: Orion-Interest <mailto:[EMAIL PROTECTED]>
> Sent: Thursday, September 06, 2001 2:23 AM
> Subject: RE: Stored procedures and J2EE
>
> As for distributing your business logic between the datastore and middle
> tier...aren't you making your life more complex than it needs to be? There
> is absolutely no hit on performance if you pull out all of your business
> logic into a slsb or cmp...there's just no need to use store procedures any
> more.
>
>
> << File: ATT00000.html >>
