Yep that's right, but only in an environment where you have the option to
connect to the middle layer with
any platform you like. Sometimes you haven't and that weighs into the
equation as well.
Guess my point is that an architecture caries some pragmatism as well.
N-tier is not a goal on itself although
it almost looks like Gartner cs. would like us to see it that way. Their
point was great when nobody was thinking
about separating data / business and views, but now we have to build
systems and not architectures.
FE
-- and yes we do have to think about the future when building systems.
On Sunday, September 09, 2001 7:46 AM, Troy Wong [SMTP:[EMAIL PROTECTED]]
wrote:
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: ATT0.html
