choices regarding where to place code - in the database or middle tier

[BarryNL]

(e-mail address removed) (Daniel Roy) wrote in message


IMHO, business-rules code should reside in the middle tier. That is
by far the most scalable solution. But ANY code that deals with data
and its storage mechanism MUST reside on the db. How to make the two
talk? That is the province of object-relational mapping design and
database design.
The rules for those have been established long ago, people just insist
on taking 1 week Java courses and believe this replaces proper training and
experience.

Close. Most employers insist on sending their consultants on 1 week
training courses and then pass them off as experts. I'm sure most
consultants would love the chance to study and train properly but the
current business world does not support that. If more companies were
willing to retain and train their own staff instead of outsourcing maybe
the skill level in the industry would be higher.

 

[Galen Boyer]

Well, I actually want thin clients, but from DBMS perspective,
the application server is not a thin client. I do believe that
no bytes should leave the DBMS that aren't needed at the end
client, but once they've left, they should be retained and
milked/reused for all they are worth,

To a point. But, the worry here is that the developer starts
down this path and ends up coding joins in the middletier. Stay
away from that and I agree.

and this can be intelligently and profitably done. Performance
and scalability follow, according to the non- volatility of the
data,

Can you explain further?

the relative proximity of the clients to the middle tier as
opposed to their distance to the DBMS, and the relaitve
lightness of the communication protocol between client and
middle tier as opposed to the protocol between DBMS and any of
it's clients.

But how "close" is the client to an EJB that has been passivated
and needs to be reactivated? What is the database but one huge
passivation/activation engine? It is clearly better at that job
than an application server. The point is that EJB's have never
really taken off because of performance and most will turn around
and just constantly query that database. We do this in our
environment and our performance is quite good.

Sure, and protecting the DBMS from uncontrolled ad-hoc
connections and mindless repeat queries,

What is a call to an EJB but a mindless repeat query to some
passivation/activation engine?

and acting as a transaction monitor/controller to get the best
performance out of the DBMS, etc.

I agree that logical transaction control should be performed by
the client requesting the operation and distributed transactions
are certainly handled quite nicely. But, if your distribution is
all Oracle, then I would still say to handle it within Oracle.

 

[Sudsy]

Noons wrote:

Minor correction: two-tier client-server is dead. Multi-tier is STILL client-server!
Not that I agree: now that we finally have the gear (CPU and memory) and network
bandwidth to make two-tier viable, what does this industry go and do? It kills it.
Brilliant...

I suppose that I'd have to be labelled an n-tier advocate. Interesting
that your viability argument, namely "the gear (CPU and memory)", is
equally applicable to n-tier.
Try to look at the situation from different prespectives. Suppose you
have a company which run P****ess. They've spent years creating their
"trigger" code using the proprietary programming language (stored
procedures didn't exist on the platform until a few years ago).
Now the business has grown to the point where P****ess represents a
liability. Too many problems, too much hands-on required for what
should be fairly basic operations. They'd like to upgrade to Oracle
but they're stuck: it would take man years of effort to rewrite the
archaic and "magical" trigger code in PL/SQL.
Or how about a small company which selects MySQL simply because it's
so cheap? (Free, actually.) A little while down the road and they
find a need for the features (on-line database backups, available
24x7) provided by an "enterprise" RDBMS like DB/2 or Oracle. If they
implemented the business logic in the middle tier then the back-end
becomes plug-and-play.
Portability is important to me, and should be for most organizations.
Tying yourself to a single vendor can severely limit your options.
Think about technologies like XML. Any computer which can read and
write text files and provides network interfaces can exchange XML
documents with any other computer without regard to architecture,
operating system, etc. Gone are the days of complicated record
structures and painful conversions.
I'm just advocating a similar approach to application design.

 

[Joe Weinstein]

There are things a lot more important than benchmarks and performance.

Well, not to some marketing types... , and I'm sure you know of businesses
whose application performance *is* a top-tier concern. Benchmarks wouldn't
be done if they didn't intend to hint at proving something that customers
want. So, let's agree that the individual customers will decide for themselves
whether (and how much) performance is important to them.

We all know all RDBMS vendors do whatever they need to get the magic
number ... the one better than the competition.

Sure, but the point is that middleware (which is used in exactly the same way
in the real world, not *just* for benchmarks) is crucial to get the best
performance out of a DBMS, even in a benchmark that is tailored specifically
to be DBMS-centric.

But all of what you refer to as "protecting the DBMS from uncontrolled
ad-hoc connections" as middle-ware is not valid on its face. You put up
the best middleware tool you can and then give me SQL*Plus, MS Access,
whatever ... and all of your protections are null and void. The
middleware only protects from those connections routed through the
middleware ... and it is for that reason specifically we see far too
much data corruption.

Well, surely you know what I mean. All your DBMS-resident protections are
also null and void if I get into your disk farm with a sledge hammer and
a tape eraser... The point is that *when used as designed and intended* by
official users, middleware can multiplex the work of thousands of users
through a small, controlled, fully-used set of full-time DBMS connections.
This saves the DBMS from polling and creating and closing thousands of
per-user, lightly used connections, and it saves the clients from the relative
slowness of making new real connections. I'm not saying that *DBMS* security
shouldn't be in the DBMS, but other security is very well done in the middle
tier too, where it can implement single-sign-on security across a set of
applications and cross-DBMS access. It provides for unified encryption of
communications etc.

I'm not arguming the valid of your company's product or middleware.

Sure. You are clearly being honest and thoughtful. You aren't an Oracle bigot.
We may both just be biassed in the other's eyes, me toward application servers,
and you toward the DBMS.

Only the fact that data security and integrity must be protected at the RDBMS
level.

I agree, but would only add that there is need for *other* security and
integrity, and even for such things as transactional integrity, the multi-
resource nature of current state-of-the-business transactions requires
external transaction coordinators to guarantee that integrity.

That you may layer a little more on top is fine but anyone
depending on it rather than the RDBMS is begging for problems.

We differ here 'a little' because I think there's *a lot* that can be offered
and built and accomplished in that middle layer (in an application-serving layer).
Depending on an external layer for what the DBMS is best at, *is* begging
for problems. However, I believe there's a lot that the DBMS can't do well,
and depending on the DBMS to do that stuff is also begging for problems, in
performance to start.
To repeat the inarguable example, the DBMS can't even do the basic job it was
designed to do by itself, in a test designed specifically to exercize a DBMS,
as fast by itself, as it can when it uses an intelligent middle tier.
We're focussing on our differences, but I am also a DBMS guy, and we would
probably agree for the most part on specific functionality that should be in
the DBMS.
Joe Weinstein at BEA

 

[Joel Garry]

The result is a monumental impedance mismatch with no solution until
more rsponsible people are put in charge of these OO-based projects.

There should be a nutshell award, and that line should win it.

jg

 

[sybrandb]

Depending on an external layer for what the DBMS is best at, *is* begging
for problems. However, I believe there's a lot that the DBMS can't do well,
and depending on the DBMS to do that stuff is also begging for problems, in
performance to start.
To repeat the inarguable example, the DBMS can't even do the basic job it was
designed to do by itself, in a test designed specifically to exercize a DBMS,
as fast by itself, as it can when it uses an intelligent middle tier.
We're focussing on our differences, but I am also a DBMS guy, and we would
probably agree for the most part on specific functionality that should be in
the DBMS.
Joe Weinstein at BEA

Apparently you have been brainwashed and consider middle-tier to be
THE Gospel, and now you are trying to brainwash others. Your assertion
'depending on the DBMS is begging for problems' demonstrates that
clearly: you simply don't know what you are talking about. I have seen
NO (I repeat NO) middle-tier applications that couldn't be qualified
as a complete DRAMA. Anyone with only a little bit of experience in
the field is aware of that.
There is NOTHING in a middle-tier that couldn't be done by a DBMS, in
most cases having it done by a middle-tier 'application' is at it's
best asking for something completely unscalable (which BTW everyone
with a little bit of experience knows).
I would contest you are a 'DBMS guy', if you really are a 'DBMS guy'
you wouldn't have made your completely erroneous claim 'depending on a
DBMS is begging for problems'
Depending on a middle-tier however IS, as everyone knows, BEGGING for
problems, especially when being used by inexperienced developers (and
middle-tier 'applications' are ONLY being developed by inexperienced
developers)

Sybrand Bakker
Senior Oracle DBA

 

[Daniel Morgan]

Apparently you have been brainwashed and consider middle-tier to be
THE Gospel, and now you are trying to brainwash others. Your assertion
'depending on the DBMS is begging for problems' demonstrates that
clearly: you simply don't know what you are talking about. I have seen
NO (I repeat NO) middle-tier applications that couldn't be qualified
as a complete DRAMA. Anyone with only a little bit of experience in
the field is aware of that.
There is NOTHING in a middle-tier that couldn't be done by a DBMS, in
most cases having it done by a middle-tier 'application' is at it's
best asking for something completely unscalable (which BTW everyone
with a little bit of experience knows).
I would contest you are a 'DBMS guy', if you really are a 'DBMS guy'
you wouldn't have made your completely erroneous claim 'depending on a
DBMS is begging for problems'
Depending on a middle-tier however IS, as everyone knows, BEGGING for
problems, especially when being used by inexperienced developers (and
middle-tier 'applications' are ONLY being developed by inexperienced
developers)

Sybrand Bakker
Senior Oracle DBA

And I hate to say it ... but if what Sybrand says wasn't true before 10g
.... take a seriously look at 10g.

--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
(e-mail address removed)
(replace 'x' with a 'u' to reply)

 

[Joe Weinstein]

Apparently you have been brainwashed and consider middle-tier to be
THE Gospel, and now you are trying to brainwash others. Your assertion
'depending on the DBMS is begging for problems' demonstrates that
clearly: you simply don't know what you are talking about.

Interesting! It seems that your misquote indicates only that you don't
know what I'm talking about... Look again. I said that depending on the
DBMS *for things that it doesn't do best* is looking for trouble.

I have seen
NO (I repeat NO) middle-tier applications that couldn't be qualified
as a complete DRAMA. Anyone with only a little bit of experience in
the field is aware of that.

What you say is true, but those with more than a little experience in the
field may differ...

There is NOTHING in a middle-tier that couldn't be done by a DBMS, in
most cases having it done by a middle-tier 'application' is at it's
best asking for something completely unscalable (which BTW everyone
with a little bit of experience knows).

Again, a little information is a dangerous thing ... I believe that
the audience that believes that there should be no middle tier, and
that having the DBMS do everything is more scaleable, is small and
preferentially populated by your group of 'everyone with a little bit
of experience'. The idea that a globally distributed application with
browser front-ends should interact directly with some DBMS is silly.
You might also actually discuss why, if the DBMS can do everything, why
it needs middleware in a pure DBMS-centric TPC-C benchmark. According
to you, it should scale better by itself. It seems you should educate
Oracle's performance team...

I would contest you are a 'DBMS guy',

I guess I'm more of a blasphemer and infidel?

if you really are a 'DBMS guy'
you wouldn't have made your completely erroneous claim 'depending on a
DBMS is begging for problems'

Misquote renoted. The point is that I'm not *only* a DBMS guy. My specialty
(since '96) is Java-database connectivity (JDBC). BEA (weblogic) developed
the first JDBC drivers for Oracle, Sybase, Informix, and MS SQLServer. Before
that, for 8 years I was (e-mail address removed), joining the startup as it's 100th-or-so
employee. I work with most DBMSes all the time, and if people stopped using
DBMSes, I'd be out of a job. I just now know that their proper purview is
not unlimited...

Depending on a middle-tier however IS, as everyone knows, BEGGING for
problems, especially when being used by inexperienced developers (and
middle-tier 'applications' are ONLY being developed by inexperienced
developers)

Sybrand Bakker
Senior Oracle DBA

I wish you well, but this seems so parochial as to be comical!
I suspect that you don't *want* to know about the success and
need for middleware, as if it threatened the Papacy of DBAs.
I'll bet the chance you'll visit the BEA site and examine the
immense customer list of global company success stories is nill,
but as others might, here's a link:

http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/customers

Joe Weinstein at BEA

 

[Joe]

Jim -

Thanks for your response. I agree with your points. I'll try to clarify my
question regarding the areas that still bother me.

Before Oracle decided to allow you to write stored procedures in Java, they
had this really nice language (as you pointed out) called PL/SQL. It seems
to allow you to do just about anything you would want to do with your data
and they've continued to enhance it with each version of Oracle. (though I
haven't looked at 10G yet myself)

Then along comes Java, a language that attempts to solve a whole different
set of problems, and not necessarily the same ones that PL/SQL was designed
for. Even without Java existing, let alone being hosted in the database, you
can still have all the same arguments about where to put your business
logic. However, at least some of the choices would be clearly delineated by
what language was being used. If you found a particular problem that had a
better solution in PL/SQL, it was going to live in the database. If either
because of the nature of the problem, or a particular programmer's facility
with something besides PL/SQL , a particular business rule or process was
expressed in another language, it would typically live outside the database.

But along comes Oracle and takes Java and hosts it in the database. (Why,
I'm not sure. Was it just to grab the Java crowd?) Now, you have a situation
where you have the very same piece of code that can live in the database or
in your middle tier. What drives the choice then?

In the Microsoft world, the situation is a bit different. SQL Server never
had as well developed a language as PL/SQL. I've still managed to support
large systems with stored procedures using T-SQL, but it lacks features that
Oracle programmers take for granted such as packages, decent error handling
(although that will be improved in the next version) , the list goes on and
on. In the Microsoft world, the database was never treated as the center of
the development universe in the way that Oracle seemed to consider their
product. But Microsoft with the next version of SQL Server, is taking a set
of languages that they developed for the middle tier, and putting it in the
database. (As opposed to the Oracle situation, this isn't even a way to
reach out to a different developer community like Java programmers, .NET
developers are already in the Microsoft camp.). When I look at the
literature on the choice Microsoft has made, what I get is a series of
examples demonstrating problems that are more easily solved in .NET than in
T-SQL. What I don't see then is any reason that I shouldn't simply have this
code in the middle tier. In fact, the more I read about it, the more I am
curious as to what drove Microsoft to put this feature in.

I've received a lot of valuable feedback from numerous people in this
thread. Some of the conversations have been at a strategic level such as "Is
it a good or bad development that database vendors seem to be merging the
database and middle tier?". What I've gleaned from the converation so far
is

1. Most people agree that you shouldn't forgo declarative referential
integrity in favor of rules in the middle tier. In that way lies data
corruption. (for those of you that disagree - please note I said "most")

2. When you get to situations that require very high performance, it's worth
taking a look at a TPC Monitor or other middleware solution. It's what
database vendor's themselves do to get the utmost best performance.

3. You can get into awkward situations by forcing everything into one layer
or another - witness some of the stories regarding various vendor packages.
One of the ways to judge where to put a particular peice of code and how to
write it, should be clarity and maintainability.

I'm still trying to clarify for myself situations that fall in the middle.
So, take a situation where the code in question will perform adequatly in
either tier, and assume we are not talking about enforcing declarative
referential rules. Where should this code go? What other factors besides
performance come into play?

To me, it's not just a theoretical question to be happily argued over a beer
or two. I currently support clients using SQL Server. In around a year, all
the .NET developers out there will be faced with this choice. Many of them I
suspect won't think much about it, but merrily use either the left mouse
click or the right to make their selection (Microsoft makes somethings way
too easy to accomplish in opinion). I'm a pragmatist enough to know that I
can't just say "Don't use this feature, put all your code in the middle tier
" or the opposite answer either. Instead, I'm looking to learn from what has
already taken place on the Oracle side of things about the consequences of
such choices.

How is code maintenance affected by these choices? Is it easier, harder, or
really has no overall effect on projects if Java code lives in two places?
Does tuning performance of code become harder?
Are people seeing cases of poorly performing instances because the Java
code being hosted is not written will?
Is this causing more situations where the programmer points at the DBA and
the DBA points at the programmer?
Who actually decides where the code should reside?
Has it caused more security issues?

I'm sure there are also other issues that I haven't thought of, which again
is the reason for posting these questions in an Oracle forum, where you've
had to deal with these issues on a practical level for several years now.

Thanks

Joe Lax
(e-mail address removed)

 

[Joe]

Well Momma always told me to try to be as polite as possible to those
prickly Oracle people, hence I tried to use complimentary terms as possible.
Yes, I'm aware of PL/SQL, and I've posted another message to the group
explaining my issues in more detail. But for your own information, since you
seem to interested, fifteen years ago I was coding in Btrieve and life way
simpler then. <g>

Joe

 

[Niall Litchfield]

Joe Weinstein <[email protected]> wrote in message

Apparently you have been brainwashed and consider middle-tier to be
THE Gospel, and now you are trying to brainwash others. Your assertion
'depending on the DBMS is begging for problems' demonstrates that
clearly: you simply don't know what you are talking about. I have seen
NO (I repeat NO) middle-tier applications that couldn't be qualified
as a complete DRAMA. Anyone with only a little bit of experience in
the field is aware of that.
There is NOTHING in a middle-tier that couldn't be done by a DBMS, in
most cases having it done by a middle-tier 'application' is at it's
best asking for something completely unscalable (which BTW everyone
with a little bit of experience knows).

Drawing graphs, working on OS files, computing complex fourier transforms. I
can't see that any of these belong in the DBMS in general. Why would anyone
use forms or C or Java to write applications anyway, just use the database.
Surely the key is doing the right stuff in the right place. The app server
guys have a *lot* of arguing to do with me around the case for database
independence and middle tier data validation etc, ISTM that this approach is
purely in the interest of app developers, but not in the interest of good
design and application owners and users. Equally arguing that the database
can and should do everything seems equally mad.


--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************

 

[Sudsy]

Joe wrote:

1. Most people agree that you shouldn't forgo declarative referential
integrity in favor of rules in the middle tier. In that way lies data
corruption. (for those of you that disagree - please note I said "most")

Since this was posted to a java newsgroup, I'd like to add that
redundancy is always a good idea. A prime example is form validation.
Even though Struts can create javascript for validating input fields
it doesn't mean that you don't also perform validation on the server
side. Validation again when inserting into a database is a good
practice. The more "checks and balances" you design into a system,
the less the likelihood of data corruption.

 

[Chris Uppal]

There is NOTHING in a middle-tier that couldn't be done by a DBMS, in
most cases having it done by a middle-tier 'application' is at it's
best asking for something completely unscalable (which BTW everyone
with a little bit of experience knows).

Again, [snip] I believe that
the audience that believes that there should be no middle tier, and
that having the DBMS do everything is more scaleable, is small and
preferentially populated by your group of 'everyone with a little bit
of experience'.

Oooh, ooh! Lovely!

-- chris

 

[Jim Kennedy]

Jim -

Thanks for your response. I agree with your points. I'll try to clarify my
question regarding the areas that still bother me.

Before Oracle decided to allow you to write stored procedures in Java, they
had this really nice language (as you pointed out) called PL/SQL. It seems
to allow you to do just about anything you would want to do with your data
and they've continued to enhance it with each version of Oracle. (though I
haven't looked at 10G yet myself)

Then along comes Java, a language that attempts to solve a whole different
set of problems, and not necessarily the same ones that PL/SQL was designed
for. Even without Java existing, let alone being hosted in the database, you
can still have all the same arguments about where to put your business
logic. However, at least some of the choices would be clearly delineated by
what language was being used. If you found a particular problem that had a
better solution in PL/SQL, it was going to live in the database. If either
because of the nature of the problem, or a particular programmer's facility
with something besides PL/SQL , a particular business rule or process was
expressed in another language, it would typically live outside the database.

But along comes Oracle and takes Java and hosts it in the database. (Why,
I'm not sure. Was it just to grab the Java crowd?) Now, you have a situation
where you have the very same piece of code that can live in the database or
in your middle tier. What drives the choice then?

In the Microsoft world, the situation is a bit different. SQL Server never
had as well developed a language as PL/SQL. I've still managed to support
large systems with stored procedures using T-SQL, but it lacks features that
Oracle programmers take for granted such as packages, decent error handling
(although that will be improved in the next version) , the list goes on and
on. In the Microsoft world, the database was never treated as the center of
the development universe in the way that Oracle seemed to consider their
product. But Microsoft with the next version of SQL Server, is taking a set
of languages that they developed for the middle tier, and putting it in the
database. (As opposed to the Oracle situation, this isn't even a way to
reach out to a different developer community like Java programmers, .NET
developers are already in the Microsoft camp.). When I look at the
literature on the choice Microsoft has made, what I get is a series of
examples demonstrating problems that are more easily solved in .NET than in
T-SQL. What I don't see then is any reason that I shouldn't simply have this
code in the middle tier. In fact, the more I read about it, the more I am
curious as to what drove Microsoft to put this feature in.

I've received a lot of valuable feedback from numerous people in this
thread. Some of the conversations have been at a strategic level such as "Is
it a good or bad development that database vendors seem to be merging the
database and middle tier?". What I've gleaned from the converation so far
is

1. Most people agree that you shouldn't forgo declarative referential
integrity in favor of rules in the middle tier. In that way lies data
corruption. (for those of you that disagree - please note I said "most")

2. When you get to situations that require very high performance, it's worth
taking a look at a TPC Monitor or other middleware solution. It's what
database vendor's themselves do to get the utmost best performance.

3. You can get into awkward situations by forcing everything into one layer
or another - witness some of the stories regarding various vendor packages.
One of the ways to judge where to put a particular peice of code and how to
write it, should be clarity and maintainability.

I'm still trying to clarify for myself situations that fall in the middle.
So, take a situation where the code in question will perform adequatly in
either tier, and assume we are not talking about enforcing declarative
referential rules. Where should this code go? What other factors besides
performance come into play?

To me, it's not just a theoretical question to be happily argued over a beer
or two. I currently support clients using SQL Server. In around a year, all
the .NET developers out there will be faced with this choice. Many of them I
suspect won't think much about it, but merrily use either the left mouse
click or the right to make their selection (Microsoft makes somethings way
too easy to accomplish in opinion). I'm a pragmatist enough to know that I
can't just say "Don't use this feature, put all your code in the middle tier
" or the opposite answer either. Instead, I'm looking to learn from what has
already taken place on the Oracle side of things about the consequences of
such choices.

How is code maintenance affected by these choices? Is it easier, harder, or
really has no overall effect on projects if Java code lives in two places?
Does tuning performance of code become harder?
Are people seeing cases of poorly performing instances because the Java
code being hosted is not written will?
Is this causing more situations where the programmer points at the DBA and
the DBA points at the programmer?
Who actually decides where the code should reside?
Has it caused more security issues?

I'm sure there are also other issues that I haven't thought of, which again
is the reason for posting these questions in an Oracle forum, where you've
had to deal with these issues on a practical level for several years now.

Thanks

Joe Lax
(e-mail address removed)



ability me

Joe,
Put the RI and business rules in the database. Anything that has to do with
maintaining data integrity and related matters goes in the database. For
Oracle, I would use pl/sql where that fits the best and use Java where that
fits best. This gives you great flexibility to allow a whole plethora of
applications written in whatever the business thinks is best to write them
in. (Java, Cobol, APL, Fortran, C, whatever) This also means you can have
client server, web based applications, multi-tiered apps, etc. all
accrssing the same database and one set of business rules applying to all of
them. This does not mean that those applications can't have logic in them,
(eg edit rules, format rules, just the database will enforce those rules.)
By putting the business rules in the database allows one point of QA for all
those applications from a data point of view. (data consistency)

Having worked for a variety of companies for a couple of decades one a
variety of projects (all involving databases) I can say from a pragmatic
point of view that it is rare that one application and only one application
is going to access the data.(I am not talking about a small address book
application)


Jim

 

[Noons]

I wish you well, but this seems so parochial as to be comical!
I suspect that you don't *want* to know about the success and
need for middleware, as if it threatened the Papacy of DBAs.
I'll bet the chance you'll visit the BEA site and examine the
immense customer list of global company success stories is nill,
but as others might, here's a link:

http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/customers

Joe, the notion that DBA's are somehow "popes" is today
old hat. It's an old TCO argument from the Microslop mob.
Proven false ages ago. DBA's nowadays are simply trained monkeys
nursing third party apps. And little else. And have been so for
years.

Customer success stories in web sites? Come on! Do you
expect that to impress someone? A little old lady maybe?

The question is not if BEA has a good middleware engine.
There is no doubt in my mind it does. Probably the best.

The question is how much of and what kind of code should be in that
middle tier. Which has got nothing to do with your experience
at Sybase/BEA, mine at IBM/Univac/Prime/Oracle/world or the price
of fish in fact. Or rather: it has everything to do with it.
It's based on experience with prior environments and technology that
we can hope to make proper decisions regarding which is the best way
to go.

So, can we go back to defining what should go where? That is should go
somewhere is a given.

 

[Joe Weinstein]

Joe, the notion that DBA's are somehow "popes" is today
old hat. It's an old TCO argument from the Microslop mob.
Proven false ages ago. DBA's nowadays are simply trained monkeys
nursing third party apps. And little else. And have been so for
years.

Well, I have more respect for them than that... And the strident
oppinions some of them have may have to do with doing hard, complicated
work which is often under-appreciated. It is also true that the
bulk of problems with these third-party apps would not exist if they
had been written with 1/10th the DBMS understanding that the DBA has.

Customer success stories in web sites? Come on! Do you
expect that to impress someone? A little old lady maybe?

I *never* said Sybrand is a little old lady! But to be serious,
even though some sites content is as trustable as those "As seen on TV"
avertisements, BEA is posting big and referenceable successes.

The question is not if BEA has a good middleware engine.
There is no doubt in my mind it does. Probably the best.

You are a gentleman and a scholar Sir. If we succeed in returning this
thread to the topic of 'where should we put logic and/or data?', I would
be interested to hear your opinion on the affirmative value of middleware.
It seems that, even when Oracle itself is asked to show how fast and scale-
able it's DBMS is, Oracle says "OK! Watch what we can do with BEA's
transaction monitor!", some other DBMS-biased still say "It's the DBMS, stupid".

The question is how much of and what kind of code should be in that
middle tier. Which has got nothing to do with your experience
at Sybase/BEA, mine at IBM/Univac/Prime/Oracle/world or the price
of fish in fact. Or rather: it has everything to do with it.
It's based on experience with prior environments and technology that
we can hope to make proper decisions regarding which is the best way
to go.

Well, not that you aren't the only one to determine what the question
is... If you follow the thread as it actually progressed and morphed,
it certainly *started* where you say, and we can try to slew it back
on course, but when I stated my DBMS experience, it was a specific
and responsive retort for a pompous supposition that I couldn't have
had such experience. And note that experience doesn't have *everything*
to do with it. Certainly much of what we can present is based on our
experience, but there is an objective reality out there, and to the
extent that our individual models of the universe are accurate, and
to the extent that our extrapolations of experience to a general model
of the world are accurate, we *do* synthesize truth, and our individual
experiences become less important as we all meet at the scientificly
correct answers.
Your point is important though. Folks statements that "In all my
experience such-and-such is always a problem or always right" lose
value as soon as there is any controversy. We should be as rigorous
as we can with logical bases for our claims. For an example, independent
of my experience of this, is it *logical* to believe that it might make
an objectively measurable performance benefit to alter an application
suite to daily cache a single list of all the names of the countries in
Europe, and have all the user interfaces refer to this list, rather than
have the user application base query the DBMS for this information hundreds
of thousands of times per day?
Data is stale (especially with Oracle's multiversion concurrency control )
as soon as the DBMS reader process releases the low-level page semaphore. The
question is "How stale do I want my data to be and still be comfortable using
it for decisions? The most parsimonious, belt-and-suspenders choice would be
implemented with serializable isolation level (and for Oracle, we also need
'select FOR UPDATE' to really disallow read data being changed during the tx).
Now we ask 'why not do this always?', and the answer is "cost, in concurrency
performance". Oracle's optimistic concurrency allows much more throughput in
real terms, in exchange for the possibility of occasional tx failure and need
to retry. Now my question is "Why should this beneficial use of optimistic
concurrency stop at the DBMS?". I contend that middleware is made to be much better
and faster at caching, distributing, synchronizing and serving data in a regime
where optimistic concurrency is beneficial and/or performance crucial.

So, can we go back to defining what should go where? That is should go
somewhere is a given.

I'd welcome it. Those that get over-quickly emotional and derogatory should
try to be more analytical, so as not to derail the subject, as well as more
credibly supporting their position.
Joe Weinstein at BEA

 

[Joe Weinstein]

Hi Niall!

it was


be in



Drawing graphs, working on OS files, computing complex fourier transforms. I
can't see that any of these belong in the DBMS in general. Why would anyone
use forms or C or Java to write applications anyway, just use the database.
Surely the key is doing the right stuff in the right place.

Yes! We should communally compile a list of those items that are good
for the DBMS to do, and those items that are best done outside, and the
tradeoffs involved in choices when something can be done in either place.

The app server
guys have a *lot* of arguing to do with me around the case for database
independence and middle tier data validation etc,

Sure! *I* tend to council against complete DBMS independence. This is not
for love or preference for a given DBMS product, but in acknowledgement
that a significant portion of the DBMSes capabilities are presented in a
proprietary way. As to data validation, I believe that there is a wide
spectrum of viable data validity, and it balances with concurrency. Middleware
provides for an architecture that gives a wide-and-finely tuneable way to
choose how much concurrency vs. currency is wanted.

ISTM that this approach is
purely in the interest of app developers, but not in the interest of good
design and application owners and users. Equally arguing that the database
can and should do everything seems equally mad.

I agree that if anyone argued that middleware should do everything, it would
be equally mad. No one has done that here, yet. Therefore we probably agree
that the counter-assertion quoted above, that having the middle tier do
anything is asking for something unscaleable, remains the current peak in
madness in this thread so far.
Joe

 

[Mike Sherrill]

The question is how much of and what kind of code should be in that
middle tier.

What code should be *only* in that middle tier, right?

 

[Daniel Morgan]

What code should be *only* in that middle tier, right?

Load balancing
Fail over

--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
(e-mail address removed)
(replace 'x' with a 'u' to reply)

 

[Noons]

Joe, if you got my yahoo e-mail reply please post it.
My ISP carks with x-posts and I can only reply consistently
via e-mail. Plus my main PC has developed MS-itis and needs a
complete re-format/reload (sigh...).
I'm using my notebook and half of my stuff is not there.