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

[Daniel Morgan]

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.

What you are counselling is that people write some of the worst possible
code and NOT take advantage of those features and capabilities that make
a product worth the money.

And just because at some point years later they MIGHT decide to change
to another product where they can once again write mediocre code with
minimal performance and scalability.

On one hand you toot BEA's horn by saying the Oracle gets its best
performance with BEA. Then you advise removing the beast's teeth and claws.

Sounds a bit schizophrenic to me. Buy my product because it makes Oracle
blazingly fast ... but when you implement it ... don't take advantage of
any of those features that make it blazingly fast.

--
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)

 

[Andrey]

What you are counselling is that people write some of the worst possible
code and NOT take advantage of those features and capabilities that make
a product worth the money.

And just because at some point years later they MIGHT decide to change
to another product where they can once again write mediocre code with
minimal performance and scalability.

On one hand you toot BEA's horn by saying the Oracle gets its best
performance with BEA. Then you advise removing the beast's teeth and claws.

Sounds a bit schizophrenic to me. Buy my product because it makes Oracle
blazingly fast ... but when you implement it ... don't take advantage of
any of those features that make it blazingly fast.

Dear Daniel! Please, provide examples of what you name "blazinly fast"
middleware products, made by Oracle.
Is it OAS ? Surely not.
So, even I DO NOT use BEA, I must admitt that you denying criticism is
groundless.

 

[Daniel Morgan]

Dear Daniel! Please, provide examples of what you name "blazinly fast"
middleware products, made by Oracle.
Is it OAS ? Surely not.
So, even I DO NOT use BEA, I must admitt that you denying criticism is
groundless.

Try not to jump into the middle of a conversation without reviewing it
from the beginning. Not one of my sentences has referred to Oracle's
middle ware. We have been discussing BEA's and its use in Oracle's TPC
benchmarks.

--
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)

 

[Andrey]

Try not to jump into the middle of a conversation without reviewing it
from the beginning. Not one of my sentences has referred to Oracle's
middle ware. We have been discussing BEA's and its use in Oracle's TPC
benchmarks.

Daniel, if this conversation is private, could you kindly mark it with some
announcement at the beginning of messages text and end?

You effervescent and excited "schizophrenic", "blazingly fast" makes me
wonder you describing some sort of cars racing and not database. So, you
boorishness please leave for you students.

 

[Stu Charlton]

What you are counselling is that people write some of the worst possible
code and NOT take advantage of those features and capabilities that make
a product worth the money.

Is it just me or is this the second time someone from c.d.o.s has
misquoted Joe?

Read the quote again: "I tend to council *against* complete DBMS
independence."

To me that says "you should use the features of the DBMS you have".
Which is consistent with Joe's argument: not everything should be
done in middleware, not everything should be done in the database. No
data that isn't needed by a client application's display should be
transferred over the wire.

There's a real knee-jerk quality to this thread. I suggest reading
google groups history for Joe Weinstein, he's pretty much had this
position for the past 6+ years I've seen him posting. Not all J2EE
types hate the DBMS (I fight the "let's rebuild the database
ourselves" line of reasoning regularily).

Cheers
Stu

 

[sybrandb]

with some
announcement at the beginning of messages text and end?

You effervescent and excited "schizophrenic", "blazingly fast" makes me
wonder you describing some sort of cars racing and not database. So, you
boorishness please leave for you students.

Andrey, how come you think you are entitled to such arrogant and rude
behavior, when you never contributed anything useful to this forum.
Could you *PLEASE* get lost? *NOW!!!!!!!!*
Leave your flames for Mr. Putin, at least he will take appropiate
action: he will put you in jail, where you belong.

Sybrand Bakker
Senior Oracle DBA

 

[Daniel Morgan]

Daniel, if this conversation is private, could you kindly mark it with some
announcement at the beginning of messages text and end?

You effervescent and excited "schizophrenic", "blazingly fast" makes me
wonder you describing some sort of cars racing and not database. So, you
boorishness please leave for you students.

Nothing private about it but you wrote; and I quote:

""blazinly fast" middleware products, made by Oracle."

My point was we have never been talking about Oracle's middleware.

By all means jump in ... just understand the topic of the conversation
before you do so. And I'm not making any statements about the speed, one
way or the other, of Oracle's middleware. It just hasn't been part of
the conversation.

--
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)

 

[Daniel Morgan]

Read the quote again: "I tend to council *against* complete DBMS
independence."

To me that says "you should use the features of the DBMS you have".
Which is consistent with Joe's argument: not everything should be
done in middleware, not everything should be done in the database.

Cheers
Stu

You are correct that Joe is not a middleware bigot. Neither am I a
back-end bigot. but I interpret the sentence above that you quote
exactly the same now as I did when I responded to it.

You either fully embrace a software and leverage it for all of its
scalability, security, and performance features or you are leaving money
on the table. The word "complete" has no value. How should it be
interpreted ... Use 78.2% of the features but not all? Maybe only 74.5%.
I know he used the word ... but it provides not a single bit of clarity.
It still translates to "don't take maximum advantage of proprietary
features".

--
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]

What you are counselling is that people write some of the worst possible
code and NOT take advantage of those features and capabilities that make
a product worth the money.

Odd, and wrong. see below.

And just because at some point years later they MIGHT decide to change
to another product where they can once again write mediocre code with
minimal performance and scalability.

On one hand you toot BEA's horn by saying the Oracle gets its best
performance with BEA. Then you advise removing the beast's teeth and claws.

Sounds a bit schizophrenic to me. Buy my product because it makes Oracle
blazingly fast ... but when you implement it ... don't take advantage of
any of those features that make it blazingly fast.

I'll try to make it clearer for you. An example of what DBMSs do well, but proprietarily,
are stored procedures. I say "use them, to the extent, and in the way a DBMS implements
them, rather than try a lowest-common-denominator SQL92-from-client model".

As to what the DBMS does not do well, and which BEA (or any other excellent
middleware manufacturer) does do well, I need say nothing. Ask Oracle's best core
performance engineers why they use BEA in their top TPC-C benchmark.

There is no dicotomy in a system that contains middleware doing what it does best
and a DBMS doing what it does best, even if in a proprietary way.

Let me know if you have any more questions,
Joe Weinstein at BEA

 

[Alfredo Novoa]

Well, I actually want thin clients, but from DBMS perspective, the application
server is not a thin client.

Indeed, from DBMS perspective the application server is a logical DBMS.

a day for each user. A current state-of-the-art application would have a generic
browser as one of it's clients, and in such a case, the middle tier is ideal for
caching the list of the countries in Europe, and making is available to all
clients

The DBMS is the ideal place, middlewares are simply a part of a distributed DBMS.


Regards
Alfredo

 

[Joe Weinstein]

Daniel Morgan wrote:

Hi Daniel. I hope my other response was clear, and this one of yours is clearer
than your first.

You either fully embrace a software and leverage it for all of its
scalability, security, and performance features or you are leaving money
on the table.

Only in a simple one-vendor environment. If you are using more than one product,
both may offer some same bit of functionality, and perhaps you cannot use them
redundantly, but must choose one or other. In this case, the money you paid
one of the vendors for the feature is already lost. You will presumably choose
to use the one that either works best, or provides some side benefit.

The word "complete" has no value. How should it be
interpreted ... Use 78.2% of the features but not all? Maybe only 74.5%.
I know he used the word ... but it provides not a single bit of clarity.
It still translates to "don't take maximum advantage of proprietary
features".

Let me make it clearer. It should be clear and obvious that the simple bank+tellers
OLTP benchmark in TPC-C can, and has been completely implemented with Oracle software.
In that configuration, Oracle's features, proprietary or not, have been used to their
utmost. However, when the stopwatch meets the marketing department, it appears that
Oracle did it's best by leaving some existing oracle functionality on the table, and
going so far as pay for some outside replacement functionality.
Therefore, the percentage you seek, 78.2% or 74.5% (or 30%) etc, depends
on the specific application, but we know that 'complete' is undesirable. It means
100%, and only the DBMS or middleware bigot say you should shower with only the
hot or cold.
Joe Weinstein at BEA

 

[Alfredo Novoa]

Minor correction: two-tier client-server is dead. Multi-tier is STILL client-server!

Indeed, it is all client-server. Tiers are physical, not logical.
There are only two logical tiers: the client and the 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.

Two tier was always viable, but the current DBMSs are fatally flawed.


Regards
Alfredo

 

[Alfredo Novoa]

There is NOTHING in a middle-tier that couldn't be done by a DBMS

Of course, middle tiers are DBMSs that use other DBMSs behind the
scenes.

, 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).

Most middle tiers have blunderous designs. A good middleware must
expose a relational interface.


Regards
Alfredo

 

[Joe Weinstein]

Indeed, it is all client-server. Tiers are physical, not logical.
There are only two logical tiers: the client and the server.


Two tier was always viable, but the current DBMSs are fatally flawed.

Regards
Alfredo

Sure, logically. The client just wants what they want, and can consider everything
they don't type in as 'the server'. I'm saying that physical client-server is dead,
as least when your clients are coming in willy-nilly from the internet, and they want
one screen to offer them stuff from your DBMS and maybe your partner's DBMSes,
and to show messages from your messaging system etc. I'm interested to know what
you mean by 'the current DBMSes are fatally flawed'. I think they are just good
at doing one difficult-but crucial class of work, and should be protected to do that
as fast as possible, by having separate independent CPUs and processes intercede
between the internets'worth of browsers, and integrate those other DBMSes, and
(blasphemy) keep a list of the countries in Europe handy for clients, rather than
have them ask the DBMS etc.
Joe

 

[Daniel Morgan]

Joe Weinstein wrote:

I'll try to make it clearer for you. An example of what DBMSs do well,
but proprietarily,
are stored procedures. I say "use them, to the extent, and in the way a
DBMS implements
them, rather than try a lowest-common-denominator SQL92-from-client model".

We are in complete agreement so far.

As to what the DBMS does not do well, and which BEA (or any other excellent
middleware manufacturer) does do well, I need say nothing. Ask Oracle's
best core performance engineers why they use BEA in their top TPC-C benchmark.

There is no dicotomy in a system that contains middleware doing what it
does best
and a DBMS doing what it does best, even if in a proprietary way.

Let me know if you have any more questions,
Joe Weinstein at BEA

Unless I interpret the above as meaning you've changed your mind I am
lost as to your original intent when you wrote that you counsel against
complete DBMS dependence. Seems like you've changed from "dependence" to
"INdependence". Was the original a typo or did I misunderstand you?

--
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)

 

[Daniel Morgan]

Daniel Morgan wrote:

Hi Daniel. I hope my other response was clear, and this one of yours is
clearer
than your first.



Only in a simple one-vendor environment. If you are using more than one
product,
both may offer some same bit of functionality, and perhaps you cannot
use them
redundantly, but must choose one or other. In this case, the money you paid
one of the vendors for the feature is already lost. You will presumably
choose
to use the one that either works best, or provides some side benefit.

As you now explain yourself I agree. Usually those words are used to
promote the concept of vanilla SQL rather than bulk binds and other
proprietary code that can vastly increases scalability and performance.

--
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]

Joe Weinstein wrote:



We are in complete agreement so far.
Coolness.


Unless I interpret the above as meaning you've changed your mind I am
lost as to your original intent when you wrote that you counsel against
complete DBMS dependence. Seems like you've changed from "dependence" to
"INdependence". Was the original a typo or did I misunderstand you?

No, the original is correct, that I council *against complete DBMS INDEPENDENCE*.
The 'IN' is intended, and in the original post. I also council against complete
DBMS-specificity, or even using the DBMS for everything it can do. For instance,
a system design could include DBMS-specific code in the middle tier and in the
DBMS to invoke and enact such proprietary things as it's stored procedures. On
the otherhand, such aspects as transactional control, *some* data caching, and
real end-user request handling and multiplexing of DBMS requests might be best
done in the in the middle tier, in addition to or instead of in the DBMS, whether
solutions to these needs were available from the DBMS in a standard or proprietary
way.
In the case of simply getting the most out of a DBMS in a simple DBMS-centric
benchmark, Oracle itself chooses not to use the DBMS itself for all it could
functionally do, but because of the radical efficiencies a middle tier offers,
they choose to use a third-party middle tier. You should be sure that the
performance benefit of such an independent middle tier must be radical for
Oracle to include it in what they would desperately want to make an Oracle-only
show. Further, it must be a valuable, non-trivial task to make and support such
a middleware product, else Oracle would have made it's own long ago.

 

[Andrey]

"Andrey" <[email protected]> wrote in message

Andrey, how come you think you are entitled to such arrogant and rude
behavior, when you never contributed anything useful to this forum.
Could you *PLEASE* get lost? *NOW!!!!!!!!*
Leave your flames for Mr. Putin, at least he will take appropiate
action: he will put you in jail, where you belong.

May be you can get lost youself?

 

[Daniel Morgan]

No, the original is correct, that I council *against complete DBMS
INDEPENDENCE*. The 'IN' is intended, and in the original post. I also
council against complete DBMS-specificity, or even using the DBMS for
everything it can do.

You are mixing together multiple incompatible concepts. Lets take them
one at a time.

Complete DBMS independence means utilizing those vendor specific
functions that optimize security, performance, and scalability. Good so far.

Having done the former ... the second is logically impossible. Once I
use a vendor specific function, for example in Oracle packages, I have
code that can not be moved anywhere else without a rewrite. You can't
have it both ways.

BTW: I normally don't correct spelling but you have used the word so
many times it begs pointing this out: The word you are looking for is
'counsel' not 'council'.

--
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]

You are mixing together multiple incompatible concepts. Lets take them
one at a time.

Complete DBMS independence means utilizing those vendor specific
functions that optimize security, performance, and scalability. Good so
far.

Having done the former ... the second is logically impossible. Once I
use a vendor specific function, for example in Oracle packages, I have
code that can not be moved anywhere else without a rewrite. You can't
have it both ways.

Please try one more time. In your first sentence you imply you'll take
several concepts one at a time. Your next sentence lists three possible
candidate 'concepts' all together. Then your last sentence only refers to
two, presumably security and performance. (What happened to scalability?).
I don't understand what you're saying. Your first sentence doesn't make
sense to me, and I think we unintentionally misunderstand this below:

In my meaning,

"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor specific
functions that optimize or implement security, performance, and scalability
(and other stuff)." Perhaps it also means "Relying on at least one DBMS vendor-
specific feature in a way that makes the system practically unable to adapt
to another DBMS".

Complete DBMS independence means that a system is not bound to a given
DBMS, because it uses only the functionality offered by the DBMS that is
accessible via DBMS-neutral syntax, that syntax which provides the same
semantics in any DBMS.

It is also true that a system could be completely dependent on a given
middle tier product if it used all the vendor-specific features of
that product. What we have been talking about is what degree of
DBMS independence a system should maintain. *Some* independence is
possible and good, and maybe even unavoidable, such as the common
semantics (for the most part) of the shared SQL language. Independence
is good because it broadens the market for the system and lowers the cost
usually. Lots of such successful systems exist.
Some dependence is unavoidable, such as having something in the DBMS
client that speaks the client-DBMS wire protocol. Some dependence/independence
is optional, such as a vendor's stored procedures. Should a system use
them, or stick to fresh SQL92? I would generally expect stored procedures
would be better, even if the system had to have multiple analogous
subsystems to attempt to duplicate functionality to different DBMSes.
On the other hand, there are some functions that the DBMS can do,
in a vendor-specific way, that I would advise against. Indeed, there
are some functions that the DBMS can do in a completely generic way,
that should nevertheless be done elsewhere. Oracle's top TPC-C benchmark
is an example of this last category.
Joe