Discussion:
choices regarding where to place code - in the database or middle tier
(too old to reply)
Joe
2004-01-19 03:26:48 UTC
Permalink
Hi -

Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.

Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.

I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.

I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.

If you are interested, please contact me at ***@dbdirections.com

Thank you

Joe Lax
Daniel Roy
2004-01-19 21:16:58 UTC
Permalink
Hi Joe,
I am a Siebel configurator/programmer (Siebel is a "Customer
Relationship Management" software, which can be considered analogous
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database. Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
almost all the code (including referential integrity!) in the middle
tier. As a result, on ALL the projects I've been a part of, we have
had data issues. The worst part is for the foreign keys which are not
valid. Other issue are about some code (usually PL/SQL) which is not
in sync with the database, for whatever reason (access rights,
objects/columns which don't exist anymore, ...). Also, performance is
always better from inside the database, from what I've seen so far.
This is logical since there is less network traffic when everything is
done from Oracle.

Just my 2 cents

Daniel
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Daniel Morgan
2004-01-19 21:28:53 UTC
Permalink
Post by Daniel Roy
Hi Joe,
I am a Siebel configurator/programmer (Siebel is a "Customer
Relationship Management" software, which can be considered analogous
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database. Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
almost all the code (including referential integrity!) in the middle
tier. As a result, on ALL the projects I've been a part of, we have
had data issues. The worst part is for the foreign keys which are not
valid. Other issue are about some code (usually PL/SQL) which is not
in sync with the database, for whatever reason (access rights,
objects/columns which don't exist anymore, ...). Also, performance is
always better from inside the database, from what I've seen so far.
This is logical since there is less network traffic when everything is
done from Oracle.
Just my 2 cents
Daniel
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Exactly mirrors my experience with Siebel, SAP, PeopleSoft, and Baan.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Eric F
2004-01-20 06:17:04 UTC
Permalink
Post by Daniel Morgan
Post by Daniel Roy
Hi Joe,
I am a Siebel configurator/programmer (Siebel is a "Customer
Relationship Management" software, which can be considered analogous
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database. Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
almost all the code (including referential integrity!) in the middle
tier. As a result, on ALL the projects I've been a part of, we have
had data issues. The worst part is for the foreign keys which are not
valid. Other issue are about some code (usually PL/SQL) which is not
in sync with the database, for whatever reason (access rights,
objects/columns which don't exist anymore, ...). Also, performance is
always better from inside the database, from what I've seen so far.
This is logical since there is less network traffic when everything is
done from Oracle.
Just my 2 cents
Daniel
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Exactly mirrors my experience with Siebel, SAP, PeopleSoft, and Baan.
Hello!

Data belongs in the database. Business logic; i.e. code, belongs in the middle
tier.

Referential integrity belongs in the database. That is data.

CRM packages typically don't perform well because, as noted, they push as much
into the middle tier due to the differences between the different databases.
But the DBMS systems are optimized for RI.

They also miss indexes which cause huge performance problems.

Replication of business logic via clusters/EJB will provide a lot of
performance improvements with code in the middle tier.

My .02

e
Niall Litchfield
2004-01-20 10:32:39 UTC
Permalink
Post by Eric F
Hello!
Data belongs in the database. Business logic; i.e. code, belongs in the middle
tier.
Referential integrity belongs in the database. That is data.
What is 'business logic' and what is 'Referential integrity'. By which I
mean Is a rule like every order must consist of fully formed header
information and at least one detail line a business rule or a database rule?

<snip>
Post by Eric F
Replication of business logic via clusters/EJB will provide a lot of
performance improvements with code in the middle tier.
At what cost?


--
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
******************************************
Mike Sherrill
2004-01-20 16:59:21 UTC
Permalink
Post by Eric F
Data belongs in the database. Business logic; i.e. code, belongs in the middle
tier.
Hmmm.
Post by Eric F
Referential integrity belongs in the database. That is data.
Where do "required data" constraints belong, as in "this value must
not be null and must not be an empty string"?

Where do range constraints belong, as in "this value must be greater
than zero"?

Where do "paired column" constraints belong, as in "end date must be
on or after start date"?
Post by Eric F
My .02
I think you overcharged me. There's a lot more to data integrity than
just referential integrity.
--
Mike Sherrill
Information Management Systems
Joe Weinstein
2004-01-19 21:45:38 UTC
Permalink
Post by Daniel Roy
Hi Joe,
I am a Siebel configurator/programmer (Siebel is a "Customer
Relationship Management" software, which can be considered analogous
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database. Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
almost all the code (including referential integrity!) in the middle
tier. As a result, on ALL the projects I've been a part of, we have
had data issues. The worst part is for the foreign keys which are not
valid. Other issue are about some code (usually PL/SQL) which is not
in sync with the database, for whatever reason (access rights,
objects/columns which don't exist anymore, ...). Also, performance is
always better from inside the database, from what I've seen so far.
This is logical since there is less network traffic when everything is
done from Oracle.
Thanks. This conversation will become richer and clearer as folks get into
it. Sure, the DBMS is a good place for simple referential integrity constraints,
as well as set-based data processing. Stored procedures and triggers are important
to do that sort of thing in one place. I knew of a payroll application that took
8 hours to do 40,000 employee run because it sucked raw data, person by person
from the DBMS to the fat client to do the real grinding. When this was converted
to 4 separately-running-but-pipelined stored procedures, it took 15 minutes to
do the same work. What *shouldn't* be in the DBMS is user session control or even
most less-volatile online data that is tapped by user applications. I saw a European
software company's product (I won't name names but it starts with "Baa" ;-) ) that
has a set of application queries, from which all useful business functions were
built. A typical user would enact a 100 or so business functions per day. Each
function had a part where it queried the DBMS for the list of countries in Europe!
Every user, hundreds of times a day! I am aware of the political flux in Europe
in the 90's but it was never that bad! ;-)
Fundamentally, you don't want every user of your application to cause/require a new
DBMS connection, let alone ask it for the same non-volatile data 10,000 times a day.
To get the best performance, applications are going to have to be DBMS-specific
at some level. DBMSes aren't dumb file systems. I knew of another application vendor,
who shall remain nameless (but it rhymes with 'beoblesoft' ;) ) that 'rolled it's
own stored procedures' by storing the SQL for every business query in the DBMS
as string data, and to do any given function, would query the DBMS for the SQL
needed, and would then send that SQL back to be executed as fresh SQL!
However, that dbms-specific level should be as narrow and controllable/switchable
as possible. J2EE standards help there.
Joe
Post by Daniel Roy
Just my 2 cents
Daniel
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Daniel Morgan
2004-01-20 23:42:46 UTC
Permalink
Post by Joe Weinstein
However, that dbms-specific level should be as narrow and
controllable/switchable
as possible. J2EE standards help there.
Joe
Post by Daniel Roy
Just my 2 cents
Daniel
I appreciate your opinion and your honesty that your perspective comes
from selling that middle tier but I completely disagree.

The 'lets push more bytes down the pipe and across all those routers'
thinking is not going to lead to performance. You may be scalable but
performance will suffer. And you will be no more scalable than a thinner
client.

Render under to database everything you can do in the database and let
the middle tier do what it does best ... fail-over, load levelling, and
serving up the front-end.

Try tuning all that rotten SQL coming from those fat front-ends sometime
and you will understand why those here that have experience with
PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-21 00:28:05 UTC
Permalink
Post by Daniel Morgan
Post by Joe Weinstein
However, that dbms-specific level should be as narrow and
controllable/switchable
as possible. J2EE standards help there.
Joe
Post by Daniel Roy
Just my 2 cents
Daniel
I appreciate your opinion and your honesty that your perspective comes
from selling that middle tier but I completely disagree.
cool.
Post by Daniel Morgan
The 'lets push more bytes down the pipe and across all those routers'
thinking is not going to lead to performance. You may be scalable but
performance will suffer. And you will be no more scalable than a thinner
client.
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, and this can be intelligently
and profitably done. Performance and scalability follow, according to the non-
volatility of the data, 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.
Post by Daniel Morgan
Render under to database everything you can do in the database and let
the middle tier do what it does best ... fail-over, load levelling, and
serving up the front-end.
Sure, and protecting the DBMS from uncontrolled ad-hoc connections and mindless
repeat queries, and acting as a transaction monitor/controller to get the best
performance out of the DBMS, etc. Otherwise you should explain why Oracle chooses
to use BEA as middleware when it simply tries to demonstrate it's own performance
potential in TPC-C benchmarks.
Post by Daniel Morgan
Try tuning all that rotten SQL coming from those fat front-ends sometime
and you will understand why those here that have experience with
PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.
Well, sure. I have done so, in fact. The stupidities are legion. Many of these
applications are ridiculous 'ports' of 70's era COBOL/ISAM applications to
'client-server' by simply swapping in row-by-row cursor fetches to the DBMS
instead of the previous ISAM call. Intelligent client-server architecture
(as I've said) puts the sawmills where the trees are, not in the client. However,
client-server is dead, at least to the extent that now everyone in the company
or the internet may want the info in the DBMS(s), and transactions now involve
serveral DBMSes and other resources. Thats where the middle tier makes it's
contribution, and depending on what's done, and what degree of concurrency,
isolation, atomicity etc that particular data requires, it can now find a
profitable home in either the DBMS or the middle tier, at least as a cache.
As an example from the Baan suite, they really did architect their application
so it queried the DBMS for a list of the countries in Europe hundreds of times
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, and given the political instability in Europe, maybe refreshing it's
list once daily from the DBMS? It saves a lot of DBMS cycles...
IMHO...
Joe
Noons
2004-01-21 10:12:10 UTC
Permalink
Post by Joe Weinstein
Well, sure. I have done so, in fact. The stupidities are legion. Many of these
applications are ridiculous 'ports' of 70's era COBOL/ISAM applications to
'client-server' by simply swapping in row-by-row cursor fetches to the DBMS
instead of the previous ISAM call.
Bingo! Worse: in many "sophisticated" instances, these "ports" end up creating
instances of classes (objects), where the row-by-row fetch is replaced by a discrete
random access SQL in a class method.

Complete with an "iterator" class that calls the method for EVERY single object
registered. Invariably, these iterator classes are used to implement set group
operations. A task that the database engine itself is many orders of magnitude more
efficient at realizing.

And the list of stupid AND moronic "port" designs goes on and on...
Post by Joe Weinstein
(as I've said) puts the sawmills where the trees are, not in the client. However,
client-server is dead, at least to the extent that now everyone in the company
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...
--
Cheers
Nuno Souto
***@yahoo.com.au.nospam
Alfredo Novoa
2004-01-26 17:13:17 UTC
Permalink
Post by Noons
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.
Post by Noons
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
Joe Weinstein
2004-01-26 17:57:23 UTC
Permalink
Post by Alfredo Novoa
Post by Noons
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.
Post by Noons
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
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
2004-01-21 14:56:00 UTC
Permalink
Post by Daniel Morgan
Render under to database everything you can do in the database and let
the middle tier do what it does best ... fail-over, load levelling,
and serving up the front-end.
Sure, and and
mindless
repeat queries, and acting as a transaction monitor/controller to get the best
performance out of the DBMS, etc. Otherwise you should explain why Oracle chooses
to use BEA as middleware when it simply tries to demonstrate it's own performance
potential in TPC-C benchmarks.
There are things a lot more important than benchmarks and performance.
We all know all RDBMS vendors do whatever they need to get the magic
number ... the one better than the competition.

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.
Post by Daniel Morgan
Try tuning all that rotten SQL coming from those fat front-ends
sometime and you will understand why those here that have experience
with PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.
Well, sure. I have done so, in fact. The stupidities are legion. Many of these
applications are ridiculous 'ports' of 70's era COBOL/ISAM applications to
'client-server' by simply swapping in row-by-row cursor fetches to the DBMS
instead of the previous ISAM call. Intelligent client-server architecture
(as I've said) puts the sawmills where the trees are, not in the client. However,
client-server is dead, at least to the extent that now everyone in the company
or the internet may want the info in the DBMS(s), and transactions now involve
serveral DBMSes and other resources. Thats where the middle tier makes it's
contribution, and depending on what's done, and what degree of concurrency,
isolation, atomicity etc that particular data requires, it can now find a
profitable home in either the DBMS or the middle tier, at least as a cache.
As an example from the Baan suite, they really did architect their application
so it queried the DBMS for a list of the countries in Europe hundreds of times
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, and given the political instability in Europe, maybe refreshing it's
list once daily from the DBMS? It saves a lot of DBMS cycles...
IMHO...
Joe
I'm not arguming the valid of your company's product or middleware. Only
the fact that data security and integrity must be protected at the RDBMS
level. That you may layer a little more on top is fine but anyone
depending on it rather than the RDBMS is begging for problems.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-21 17:01:02 UTC
Permalink
Post by Daniel Morgan
Post by Daniel Morgan
Render under to database everything you can do in the database and
let the middle tier do what it does best ... fail-over, load
levelling, and serving up the front-end.
Sure, and and mindless
repeat queries, and acting as a transaction monitor/controller to get the best
performance out of the DBMS, etc. Otherwise you should explain why Oracle chooses
to use BEA as middleware when it simply tries to demonstrate it's own performance
potential in TPC-C benchmarks.
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.
Post by Daniel Morgan
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.
Post by Daniel Morgan
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.
Post by Daniel Morgan
Post by Daniel Morgan
Try tuning all that rotten SQL coming from those fat front-ends
sometime and you will understand why those here that have experience
with PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.
Well, sure. I have done so, in fact. The stupidities are legion. Many of these
applications are ridiculous 'ports' of 70's era COBOL/ISAM
applications to
'client-server' by simply swapping in row-by-row cursor fetches to the DBMS
instead of the previous ISAM call. Intelligent client-server architecture
(as I've said) puts the sawmills where the trees are, not in the client. However,
client-server is dead, at least to the extent that now everyone in the company
or the internet may want the info in the DBMS(s), and transactions now involve
serveral DBMSes and other resources. Thats where the middle tier makes it's
contribution, and depending on what's done, and what degree of concurrency,
isolation, atomicity etc that particular data requires, it can now find a
profitable home in either the DBMS or the middle tier, at least as a cache.
As an example from the Baan suite, they really did architect their application
so it queried the DBMS for a list of the countries in Europe hundreds of times
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, and given the political instability in Europe, maybe
refreshing it's
list once daily from the DBMS? It saves a lot of DBMS cycles...
IMHO...
Joe
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. :)
Post by Daniel Morgan
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.
Post by Daniel Morgan
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
s***@yahoo.com
2004-01-22 12:23:00 UTC
Permalink
Post by Joe Weinstein
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
2004-01-22 14:16:20 UTC
Permalink
Post by s***@yahoo.com
Post by Joe Weinstein
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
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-22 17:23:36 UTC
Permalink
Post by s***@yahoo.com
Post by Joe Weinstein
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.
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.
Post by s***@yahoo.com
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... ;)
Post by s***@yahoo.com
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...
Post by s***@yahoo.com
I would contest you are a 'DBMS guy',
I guess I'm more of a blasphemer and infidel? ;)
Post by s***@yahoo.com
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 ***@sybase.com, 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... ;)
Post by s***@yahoo.com
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
Chris Uppal
2004-01-23 23:29:48 UTC
Permalink
Post by s***@yahoo.com
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
Noons
2004-01-24 10:03:39 UTC
Permalink
Post by Joe Weinstein
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,
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.
--
Cheers
Nuno Souto
***@yahoo.com.au.nospam
Mike Sherrill
2004-01-25 10:58:25 UTC
Permalink
On Sat, 24 Jan 2004 21:03:39 +1100, "Noons"
Post by Noons
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?
--
Mike Sherrill
Information Management Systems
Daniel Morgan
2004-01-25 15:32:11 UTC
Permalink
Post by Mike Sherrill
On Sat, 24 Jan 2004 21:03:39 +1100, "Noons"
Post by Noons
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?
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-24 18:42:24 UTC
Permalink
Post by Noons
Post by Joe Weinstein
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,
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.
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.
Post by Noons
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.
Post by Noons
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".
Post by Noons
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.
Post by Noons
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
Noons
2004-01-26 06:13:57 UTC
Permalink
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.
--
Cheers
Nuno Souto
snip...
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
Niall Litchfield
2004-01-23 19:04:03 UTC
Permalink
Post by s***@yahoo.com
Post by Joe Weinstein
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).
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
******************************************
Joe Weinstein
2004-01-24 19:06:18 UTC
Permalink
Hi Niall!
Post by Daniel Morgan
Post by s***@yahoo.com
Post by Joe Weinstein
Depending on an external layer for what the DBMS is best at, *is*
begging
Post by s***@yahoo.com
Post by Joe Weinstein
for problems. However, I believe there's a lot that the DBMS can't do
well,
Post by s***@yahoo.com
Post by Joe Weinstein
and depending on the DBMS to do that stuff is also begging for problems,
in
Post by s***@yahoo.com
Post by Joe Weinstein
performance to start.
To repeat the inarguable example, the DBMS can't even do the basic job
it was
Post by s***@yahoo.com
Post by Joe Weinstein
designed to do by itself, in a test designed specifically to exercize a
DBMS,
Post by s***@yahoo.com
Post by Joe Weinstein
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
Post by s***@yahoo.com
Post by Joe Weinstein
probably agree for the most part on specific functionality that should
be in
Post by s***@yahoo.com
Post by Joe Weinstein
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).
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.
Post by Daniel Morgan
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.
Post by Daniel Morgan
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
Post by Daniel Morgan
--
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
******************************************
Daniel Morgan
2004-01-26 06:29:39 UTC
Permalink
Post by Joe Weinstein
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Andrey
2004-01-26 09:20:14 UTC
Permalink
Post by Daniel Morgan
Post by Joe Weinstein
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.
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
2004-01-26 09:30:46 UTC
Permalink
Post by Daniel Morgan
Post by Daniel Morgan
Post by Joe Weinstein
Sure! *I* tend to council against complete DBMS independence. This is
not
Post by Daniel Morgan
Post by Joe Weinstein
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.
Post by Daniel Morgan
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.
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Andrey
2004-01-26 09:44:16 UTC
Permalink
Post by Daniel Morgan
Post by Daniel Morgan
Post by Daniel Morgan
Post by Joe Weinstein
Sure! *I* tend to council against complete DBMS independence. This is
not
Post by Daniel Morgan
Post by Joe Weinstein
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.
Post by Daniel Morgan
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.
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.
s***@yahoo.com
2004-01-26 15:12:07 UTC
Permalink
Post by Andrey
Post by Andrey
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.
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
Andrey
2004-01-27 09:33:12 UTC
Permalink
Post by Joe
Post by Andrey
Post by Andrey
Daniel, if this conversation is private, could you kindly mark it
with some
Post by Andrey
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.
May be you can get lost youself?
Daniel Morgan
2004-01-26 16:04:38 UTC
Permalink
Post by Andrey
Post by Daniel Morgan
Post by Daniel Morgan
Post by Daniel Morgan
Post by Joe Weinstein
Sure! *I* tend to council against complete DBMS independence. This is
not
Post by Daniel Morgan
Post by Joe Weinstein
for love or preference for a given DBMS product, but in acknowledgement
that a significant portion of the DBMSes capabilities are presented in
a
Post by Daniel Morgan
Post by Daniel Morgan
Post by Daniel Morgan
Post by Joe Weinstein
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.
Post by Daniel Morgan
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.
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.
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Stu Charlton
2004-01-26 13:34:18 UTC
Permalink
Post by Daniel Morgan
Post by Joe Weinstein
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.
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
Daniel Morgan
2004-01-26 16:09:47 UTC
Permalink
Post by Stu Charlton
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-26 17:10:06 UTC
Permalink
Daniel Morgan wrote:

Hi Daniel. I hope my other response was clear, and this one of yours is clearer
than your first.
Post by Daniel Morgan
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.
Post by Daniel Morgan
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
Daniel Morgan
2004-01-26 18:07:32 UTC
Permalink
Post by Joe Weinstein
Hi Daniel. I hope my other response was clear, and this one of yours is clearer
than your first.
Post by Daniel Morgan
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.
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-26 16:42:48 UTC
Permalink
Post by Daniel Morgan
Post by Joe Weinstein
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.
Odd, and wrong. see below.
Post by Daniel Morgan
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
Daniel Morgan
2004-01-26 18:06:11 UTC
Permalink
Joe Weinstein wrote:

<snipped>
Post by Joe Weinstein
Post by Daniel Morgan
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".
We are in complete agreement so far.
Post by Joe Weinstein
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-26 19:39:42 UTC
Permalink
Post by Daniel Morgan
<snipped>
Post by Joe Weinstein
Post by Daniel Morgan
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".
We are in complete agreement so far.
Coolness.
Post by Daniel Morgan
Post by Joe Weinstein
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?
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.
Daniel Morgan
2004-01-28 06:37:35 UTC
Permalink
Post by Joe Weinstein
Post by Daniel Morgan
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.
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
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-28 17:26:18 UTC
Permalink
Post by Daniel Morgan
Post by Joe Weinstein
Post by Daniel Morgan
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.
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
Daniel Morgan
2004-01-29 08:33:04 UTC
Permalink
Post by Joe Weinstein
Post by Daniel Morgan
Post by Joe Weinstein
Post by Daniel Morgan
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.
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
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
We are going to have to end this one with a total disagreement. Having
spent more than 33 years in IT and more than 15 of them with relational
databases I have yet to ever see an example of:

"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance, and
scalability (and other stuff)"

and

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

What you suggest is a logical impossibility.

In Oracle, for example, there is no better place to put code than in a
package; for numerous reasons. No other database vendor has the concept
... therefore throw packages away.

In Oracle and DB2 the best way to do numering is with a sequence. SQL
Server and Sybase don't have them so throw sequences away. Of course SQL
Server and Sybase have autonumbering that Oracle doesn't have so throw
autonumbering away too. Guess we won't have any surrogate keys except by
wrapping your own ... now that's generic. All we need to do now is
recompile for every operating system.

Sorry Joe ... but your attempt to construe development to sell your
company's product is a great way to do some things. Creating high
performance scalable databases isn't one of them. Not once has Oracle
won a benchmark contest with BEA using generic code. No one else will
either.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Stu Charlton
2004-01-29 18:49:51 UTC
Permalink
Post by Joe Weinstein
"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance, and
scalability (and other stuff)"
and
"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"
What you suggest is a logical impossibility.
I think I understand completely what Joe is trying to say, so I doubt
it is a logical impossibliity. I suggest it's a communications gap.
Post by Joe Weinstein
In Oracle, for example, there is no better place to put code than in a
package; for numerous reasons. No other database vendor has the concept
... therefore throw packages away.
That's not the suggestion at all. Packages are good things and should
be used in any case you have stored procedures.
Post by Joe Weinstein
In Oracle and DB2 the best way to do numering is with a sequence. SQL
Server and Sybase don't have them so throw sequences away. Of course SQL
Again, that's not the case. Keep your sequences.
Post by Joe Weinstein
Sorry Joe ... but your attempt to construe development to sell your
company's product is a great way to do some things. Creating high
performance scalable databases isn't one of them. Not once has Oracle
won a benchmark contest with BEA using generic code. No one else will
either.
I think the point is not about generic vs. specific code. Genericity
is a trade-off against performance, and isn't always applicable.

The point, I believe, is about trade-offs of what features to use when
you are building a commercial distributed system that involves several
product sets. Performance is usually the primary consideration with
any large system, but it rarely is the only consideration (except,
perhaps, for benchmarks).

Having said that, one might look at the TPC benchmark, as Joe has
pointed out, and wonder why they used BEA Tuxedo instead of Pro*C with
Oracle Shared Server / MTS. Tuxedo performs the same feature of
pooling / dispatching. Does it do it better than Shared Server? I
don't know - perhaps it's used out of inertia. But it is used, and
may successful systems have been built with such an approach. This is
an example of choosing the feature set of one product over Oracle's
equivalent.

Another example: sometimes, for skills support and maintainence
reasons, it makes sense to develop the presentation features of a
system (i.e. the dynamic web page generation) into a language such as
Java or C# -- something other than PL/SQL. Object oriented languages
are useful alternatives to procedural languages. In fact, this is
something that Oracle supports out of the box with Oracle 9i's HTTP
server and JSP runtime. This is not to say that it couldn't be done
with PL/SQL, it is to say the context of the situation may involve
tradeoffs.

Is the introduction of a middle tier an unscalable approach? Well
this is really a question of how you would like your parallelism - in
the database engine, or across server platforms (i.e. database +
middleware). Perhaps now with RAC, everything (including the web
server) could be on the same cluster and be more scalable. But
historically it has made sense to use different product sets for their
different strengths - TP monitors for their presentation libraries and
multiplexing support, Web Servers for their static file-serving
capabilities, and Oracle for its ability to chug through massive
amounts of data.

As for benchmarks...The TPC-C benchmark isn't a great example of how
to design an application - if you look at it, it actually doesn't
really use stored procedures that much, most of its SQL statements are
in C macros. It also uses multiple block sizes to try to get some
kind of performance enhancement, which as has been discussed in this
newsgroup, is of questionable value. Plus the TPC spec itself has a
rather odd setup scenario which has had an unrealistic affinity
towards shared-nothing clusters (notwithstanding the fact that a
shared-disk RAC configuration now holds the #1 spot).

Cheers
Stu
Daniel Morgan
2004-01-29 19:01:56 UTC
Permalink
Post by Stu Charlton
Post by Joe Weinstein
"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance, and
scalability (and other stuff)"
and
"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"
What you suggest is a logical impossibility.
I think I understand completely what Joe is trying to say, so I doubt
it is a logical impossibliity. I suggest it's a communications gap.
Post by Joe Weinstein
In Oracle, for example, there is no better place to put code than in a
package; for numerous reasons. No other database vendor has the concept
... therefore throw packages away.
That's not the suggestion at all. Packages are good things and should
be used in any case you have stored procedures.
Post by Joe Weinstein
In Oracle and DB2 the best way to do numering is with a sequence. SQL
Server and Sybase don't have them so throw sequences away. Of course SQL
Again, that's not the case. Keep your sequences.
Post by Joe Weinstein
Sorry Joe ... but your attempt to construe development to sell your
company's product is a great way to do some things. Creating high
performance scalable databases isn't one of them. Not once has Oracle
won a benchmark contest with BEA using generic code. No one else will
either.
I think the point is not about generic vs. specific code. Genericity
is a trade-off against performance, and isn't always applicable.
The point, I believe, is about trade-offs of what features to use when
you are building a commercial distributed system that involves several
product sets. Performance is usually the primary consideration with
any large system, but it rarely is the only consideration (except,
perhaps, for benchmarks).
Please acknowledge that once your code is in packages and you are using
sequences ... the code absolutely can not be compatible with code
written for any other database product: No exceptions. It just will not
be compatible and no quantity of bubble gum, paper clips, or rubber
bands is going to make it compatible.

So while I will gladly acknowledge a communication gap I still can't get
past thinking what you guys are proposing is a logical impossibility. If
you disagree, and I suspect you do/will, then please provide an example
of how you could use packages and sequences in Oracle and meet your
stated objective.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Stu Charlton
2004-01-30 00:57:08 UTC
Permalink
Post by Daniel Morgan
Please acknowledge that once your code is in packages and you are using
sequences ... the code absolutely can not be compatible with code
written for any other database product: No exceptions. It just will not
be compatible and no quantity of bubble gum, paper clips, or rubber
bands is going to make it compatible.
Acknowledged.
Post by Daniel Morgan
So while I will gladly acknowledge a communication gap I still can't get
past thinking what you guys are proposing is a logical impossibility. If
you disagree, and I suspect you do/will, then please provide an example
of how you could use packages and sequences in Oracle and meet your
stated objective.
Ok.

Requirement: A web-page that displays all of the employees in a given
department.

Solutions that are completely dependent on the database's feature set:
a. Build it with Marvel / HTML DB
b. Build it with mod_plsql and Oracle HTTP Server

Solutions that while still dependent on the database's feature set
(i.e. packages and stored procedures), it uses another technology for
its presentation logic:
a. Build it with mod_perl
b. Build it with JSP
c. Build it with ASP.NET

So, here's an example with ASP.NET (which I actually took and modified
into C# .NET from http://osi.oracle.com/~tkyte/ResultSets/index.html).
It's untested pseudocode, so probably has minor bugs in the ASP page.

CREATE OR REPLACE
PACKAGE DEPARTMENT AS
TYPE  CURSOR_TYPE IS REF CURSOR;
PROCEDURE GET_EMPS (I_DEPTNO     IN  NUMBER,
                O_RESULT_SET OUT CURSOR_TYPE);
END;
/

CREATE OR REPLACE
PACKAGE BODY DEPARTMENT AS
PROCEDURE GET_EMPS (I_DEPTNO     IN  NUMBER,
                     O_RESULT_SET OUT CURSOR_TYPE)
AS
BEGIN
OPEN O_RESULT_SET FOR
     SELECT EMPNO, ENAME
     FROM EMP
     WHERE DEPTNO = I_DEPTNO;
END;
END;

employees.aspx:

<%@ Page language="c#" %>
<%@ Import Namespace="System.Data" %>
<html>
<body>
 <h2>Query Employees in Department Code</h2>
 <form id="Form1" method="post" runat="server">
<asp:textbox id="DeptCode" runat="server"/>
<asp:button id="Submit" runat="server" Text="Run Query"/>
<asp:DataGrid id="MyDataGrid" runat="server" width="800" />
</form>
<script language="c#" runat="server">
void Page_Load(object src, EventArgs e) {
Submit += new System.EventHandler( RunQuery );
}
void RunQuery(object src, EventArgs e) {
OracleConnection conn = new OracleConnection();
OracleCommand cmd = new OracleCommand();
conn.ConnectionString = "data
source="oracle.server;uid=scott;password=tiger";
cmd.Connection = conn;
cmd.CommandText = "SCOTT.DEPARTMENT.GET_EMPS";
cmd.CommandType = CommandType.StoredProcedure;
OracleParameter i_deptno =
cmd.Parameters.Add("I_DEPTNO",
OracleClient.OracleType.Number);
i_deptno.Direction = ParameterDirection.Input;
OracleParameter o_resultset =
cmd.Parameters.Add("O_RESULT_SET",
OracleClient.OracleType.Cursor);
o_resultset.Direction = ParameterDirection.Output;
conn.Open();

i_deptno.Value = Int32.Parse ( DeptCode.Text );
OracleDataReader results = cmd.ExecuteReader();
MyDataSet.DataSource = results;
MyDataSet.DataBind();
}
</script>
</body>
</html>

The whole point of this is that we *didn't* use the Oracle-built in
features of HTML DB or mod_plsql, even though many successful people
CAN do so. It's really a matter of tradeoff of available skills,
future maintenance, and performance. In this case, I don't really
think the ASP.NET approach is any less scalable than Oracle-only
approaches.

The problem that too many Java or .NET folks cause is that they
re-invent database features all the time in the misguided attempt to
be "generic" because they don't want to be tied to their database
economically. This is not appropriate and is usually too drastic a
trade-off.

Anyhow, I can't speak for Joe, but this is my understanding of the
viewpoint.

Cheers
Stu
Daniel Morgan
2004-01-30 05:57:10 UTC
Permalink
Post by Stu Charlton
Post by Daniel Morgan
So while I will gladly acknowledge a communication gap I still can't get
past thinking what you guys are proposing is a logical impossibility. If
you disagree, and I suspect you do/will, then please provide an example
of how you could use packages and sequences in Oracle and meet your
stated objective.
Ok.
Requirement: A web-page that displays all of the employees in a given
department.
Cheers
Stu
First let me say you have my admiration. You put in effort and made an
attempt at answering my query. But the problem is that your example very
carefully, perhpas even artfully, dodged the issue I put in front of you
like a charging rhinoceros. What I asked was "please provide an example
of how you could use PACKAGES and SEQUENCES in Oracle and meet your
stated objective" ... and you didn't.

By selecting as your example: "A web-page that displays" you eliminated
anything having to do with sequences. What I was trying to get you to
deal with was issues related to insert, update, and delete. Issues that
involve sequences but also the transaction and locking models that are
totally different between commercial database products.

So the response while impressive is unsatisfactory in that it didn't
address the issue. And the stuff about Project Marvel ... as marvelous
as it may be ... has nothing to do with the back-end database ...
HTML_DB is a front-end tool. Could I impose upon you to try again this
time addressing this issues around transaction processing.

I still content that you can't have your cake and eat it too.

Thanks.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Noons
2004-01-30 11:41:07 UTC
Permalink
"Daniel Morgan" <***@x.washington.edu> wrote in message news:***@yasure...

Sorry folks, I'm reducing the number of x-posts otherwise my ISP will kill
my replies: thank God ONE provider is taking an active stance against
spam on Usenet, I say!
Post by Daniel Morgan
By selecting as your example: "A web-page that displays" you eliminated
anything having to do with sequences. What I was trying to get you to
deal with was issues related to insert, update, and delete. Issues that
involve sequences but also the transaction and locking models that are
totally different between commercial database products.
So the response while impressive is unsatisfactory in that it didn't
address the issue. And the stuff about Project Marvel ... as marvelous
as it may be ... has nothing to do with the back-end database ...
HTML_DB is a front-end tool. Could I impose upon you to try again this
time addressing this issues around transaction processing.
I can see your point. But I think you are approaching it from the wrong
angle.
The whole argument about wrappers is precisely to hide an implementation
from a design requirement.

The concern is not if one database has a sequence and another has an auto
sequence column.

The (design) concern is: I want a surrogate key on EVERY relational row
storing my object data and an ID for my persistent object instance data.
Period.

Now, how do I implement this? Well, I create a wrapper that says:
give me the *object* instance data and I'll store it on a number of tables
(or one single table, none of your business!).

The wrapper now calls Servant_Store_My_Object() *IF* I'm running this
middleware
against a Microslop databases. It will instead call
Larry_Store_My_Data_Cheap() *IF*
I'm running this against Larry-base 10g. And
Itty_Bitty_Wake_Up_And_Store_This()
*IF* I manage to run this against ASS400-2. A config toggle, stored in XML.

Now, how do I code EACH one of those interface/class modules above? For the
sake of
example, the Microslop one will just do a plain insert, then interrogate the
row
just created to return the generated autogen key back to the caller (as part
of a confirmation that the row(s) has/have indeed been stored).
The Larry-base one simply calls a package that handles all access to the
table(s)
and INSIDE the package it'll do whatever has to be done to use a sequence
and return
a surrogate key with the data. The ASS400-2 will probably use sacrificial
virgins.

Now, this whole thing is (partially) what is called Object-Relational
mapping and is
what has been *missing* from this entire discussion. You CANNOT hope to
answer or solve
any design problem or issues between OO programming and Relational DB
storage *without*
that mapping up-front. It's like trying to shove snow with a toothpick.

Once you start from the OO-relational mapping, then the problem is of simple
solution
as I'm quite sure you have already seen.

Wrappers deal with and handle impedance mismatches, which is what this
problem is all
about.

What also must be defined is WHICH PORTIONS of the OO-relational mapping
should be
executed in the middleware and which ones need to be executed in the
database.

If the database does or does not support one specific data-storage feature
or runs
more efficiently using ANSI-SQL stored code, PL/SQL, Transact-SQL or square
wheels
is totally immaterial (or should be...) to the middleware people.


My contention: Use whatever feature of each database better handles the
required
functionality. Do *NOT* code the handling of thsi feature in the
middleware. Code
the handling in whatever makes more sense to the database engines you have
to
support.

THEN, write a wrapper that "understands" how to call each interface to each
specific database and get it to do the dirt work. That wrapper should run
in
the middleware and should NOT assume that each object is gonna be stored in
a
single row!

It should be concerned only with persisting or retrieving an object
hierarchy by
calling the adequate class methods for EACH supported database. Or
performing
a data transformation on that hierarchy and persisting that transformation
to
the dbs. And any other performance specific functionality that is needed on
a
OO-relational map. Like, NOT considering a join as a method of an object
but an
interface to another object that represents the result. That way one can do
proper efficient joins in the database. Instead of the moronic and usual
"I'll
do the joins in middleware thank you". Responsible for so many disasters
out there...

This can of course be extended for even more modularity, but the gist of the
principle
is this. Keep the object handling in the middleware and the data storage
specifics
in the database. The bit in the middle can stay in the middleware. Or for
full
scalability, it may be split between handling the object mapping on the app
server
and handling the storing of that object data in the stored database code.
In the middle,
you pass (in old language) records. Record types. Supported by just about
every
database with stored code execution.

And so on... The subject is quite extensive.
--
Cheers
Nuno Souto
Post by Daniel Morgan
I still content that you can't have your cake and eat it too.
but let's try, no? ;)
--
Cheers
Nuno Souto
***@yahoo.com.au.nospam
Daniel Morgan
2004-01-30 15:48:54 UTC
Permalink
Post by Noons
Sorry folks, I'm reducing the number of x-posts otherwise my ISP will kill
my replies: thank God ONE provider is taking an active stance against
spam on Usenet, I say!
Post by Daniel Morgan
By selecting as your example: "A web-page that displays" you eliminated
anything having to do with sequences. What I was trying to get you to
deal with was issues related to insert, update, and delete. Issues that
involve sequences but also the transaction and locking models that are
totally different between commercial database products.
So the response while impressive is unsatisfactory in that it didn't
address the issue. And the stuff about Project Marvel ... as marvelous
as it may be ... has nothing to do with the back-end database ...
HTML_DB is a front-end tool. Could I impose upon you to try again this
time addressing this issues around transaction processing.
I can see your point. But I think you are approaching it from the wrong
angle.
The whole argument about wrappers is precisely to hide an implementation
from a design requirement.
The concern is not if one database has a sequence and another has an auto
sequence column.
The (design) concern is: I want a surrogate key on EVERY relational row
storing my object data and an ID for my persistent object instance data.
Period.
I understand and agree. I've used wrappers many times myself.

But at some point you have got to step up to the plate and put that code
into a package or use a sequence to generate that surrogate key.

And when you do everything from that point on down is vendor specific.
It is not going to be implemented against any other vendor's product
without a rewrite.

So does the wrapper allow you to implement a single front-end against
multiple back-ends ... absolutely ... and your explanation was great.
But you are still hand-coding at some point against a specific RDBMS.

So lets go back to the original discussion that started off between
myself and Joe. Joe works for BEA and was advocating what I took to be a
bit of schizophrenia ... dependence and independence.

If what you have written is what he meant the miscommunication has been
reconciled. Thanks.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-30 16:42:47 UTC
Permalink
Post by Daniel Morgan
Post by Noons
Sorry folks, I'm reducing the number of x-posts otherwise my ISP will kill
my replies: thank God ONE provider is taking an active stance against
spam on Usenet, I say!
Post by Daniel Morgan
By selecting as your example: "A web-page that displays" you eliminated
anything having to do with sequences. What I was trying to get you to
deal with was issues related to insert, update, and delete. Issues that
involve sequences but also the transaction and locking models that are
totally different between commercial database products.
So the response while impressive is unsatisfactory in that it didn't
address the issue. And the stuff about Project Marvel ... as marvelous
as it may be ... has nothing to do with the back-end database ...
HTML_DB is a front-end tool. Could I impose upon you to try again this
time addressing this issues around transaction processing.
I can see your point. But I think you are approaching it from the wrong
angle.
The whole argument about wrappers is precisely to hide an implementation
from a design requirement.
The concern is not if one database has a sequence and another has an auto
sequence column.
The (design) concern is: I want a surrogate key on EVERY relational row
storing my object data and an ID for my persistent object instance data.
Period.
I understand and agree. I've used wrappers many times myself.
But at some point you have got to step up to the plate and put that code
into a package or use a sequence to generate that surrogate key.
And when you do everything from that point on down is vendor specific.
It is not going to be implemented against any other vendor's product
without a rewrite.
So does the wrapper allow you to implement a single front-end against
multiple back-ends ... absolutely ... and your explanation was great.
But you are still hand-coding at some point against a specific RDBMS.
So lets go back to the original discussion that started off between
myself and Joe. Joe works for BEA and was advocating what I took to be a
bit of schizophrenia ... dependence and independence.
Hi. Yes, you did misunderstand, and I'm glad it's cleared up, and thanks
to Nuno and Stu for the contributions. As you can see, an application
can (and as I have always suggested, should) use DBMS-specific code in
cases where it offers major benefits. However, the application is well served
to isolate DBMS-specific code to a wrapper layer, making the bulk of
the application DBMS-neutral if possible. Further, I am just pointing out
that even within the DBMS-specific layer, or just above that at the application's
hopefully generic DBMS API layer, there may well be some DBMS functionality
(whether generic or DBMS-specific) that an application may be better served
to not use, and rely instead on an implementation in middleware. (Joins on
tabular data is *not* an example ;) ). An example of such functionality is
having middleware multiplex between a wide-ranging fluctuating population of
ad-hoc application users and the DBMS by maintaining and optimally using a
small dedicated well-used shared set of DBMS connections, instead of allowing
every application user to create an independent DBMS connection for every user
session. Another example is in the trivial caching of non-volatile data so
the DBMS is not harried with 100,000 identical queries per day for a list
of the countries in Europe. Transaction monitoring/control is another, amply
proven by all currently competitive TPC benchmarks.
This defines a grey scale of dependence/independence, which should be useful in
clearing up any remaining cognitive dissonance.

Joe Weinstein at BEA
Stu Charlton
2004-01-30 16:46:15 UTC
Permalink
"Noons" <***@yahoo.com.au> wrote in message news:<401a42f4$0$5224$***@news.optusnet.com.au>...

Well, it seems Nuno jumped ahead 2 weeks to where the thread would
probably wind up ;)
Post by Noons
This can of course be extended for even more modularity, but the gist of the
principle is this. Keep the object handling in the middleware and the data
storage specifics in the database.
That's pretty much the point. Thanks.
Post by Noons
And so on... The subject is quite extensive.
Very much so. O/R mapping has been evolving for over 10 years and
it's only recently that you're starting to see a discipline emerging.

On the other hand, whenever I scratch a team re-inventing the wheel
outside of the database, I find lurking underneath the classic
"developer/DBA conflict", which is usually the fault of management for
not properly defining roles and principles. This leads developers to
use technical means to solve an IT management or interpersonal
problem. Not to fault them of course, given the sorry state of
'management'.

Cheers
Stu
Noons
2004-01-31 12:53:46 UTC
Permalink
Post by Stu Charlton
Well, it seems Nuno jumped ahead 2 weeks to where the thread would
probably wind up ;)
Ooooh! sorry....
:)
Post by Stu Charlton
Very much so. O/R mapping has been evolving for over 10 years and
it's only recently that you're starting to see a discipline emerging.
Exactly. I spent the last two and a half years involved in an Air Force
project: we started from a perspective of "everything in the db"
and as we progressed, we moved plenty off it. As we realized it made no
sense to keep it in the db.

Part of the exercise involved rationalising what we did initially and
apply whatever principles of O-R mapping we could find or identify that
actually made sense.

There is a lot of material out there, but 90% of it is fluff:

- stuff that someone used in ONE project and is now "rule for all". Won't
mention
any names but some know exactly what I'm talking about...
- stuff that started from the "all in Java" and went the other way to make it
work fast. With shortcuts galore and just plain incorrect ideas.
- stuff that just plain didn't make ANY sense.
- and finally, little bits and pieces that we could use and adapt and
had a solid theoretical background.

There are some very interesting materials in OTN, Oracle magazine and Metalink,
but you gotta dig deep! Cameron O'Rourke has written some of the best
materials I've ever seen on this subject. Worth a read for those who may want
to
get an idea of what I'm talking about. We based most of our design on some of
his ideas and suggestions. The result was lightening fast and very, very
efficient.
And easy to maintain as well!
Post by Stu Charlton
On the other hand, whenever I scratch a team re-inventing the wheel
outside of the database, I find lurking underneath the classic
"developer/DBA conflict", which is usually the fault of management for
not properly defining roles and principles. This leads developers to
use technical means to solve an IT management or interpersonal
problem. Not to fault them of course, given the sorry state of
'management'.
100% agreed...
--
Cheers
Nuno Souto
***@yahoo.com.au.nospam
Stu Charlton
2004-01-30 17:03:02 UTC
Permalink
Post by Daniel Morgan
First let me say you have my admiration. You put in effort and made an
attempt at answering my query. But the problem is that your example very
carefully, perhpas even artfully, dodged the issue I put in front of you
like a charging rhinoceros. What I asked was "please provide an example
of how you could use PACKAGES and SEQUENCES in Oracle and meet your
stated objective" ... and you didn't.
You're right. It wasn't intentional, I just wanted to whip something
up relatively quickly.
Post by Daniel Morgan
By selecting as your example: "A web-page that displays" you eliminated
anything having to do with sequences. What I was trying to get you to
deal with was issues related to insert, update, and delete. Issues that
involve sequences but also the transaction and locking models that are
totally different between commercial database products.
We can get into that if you'd like, but I'm well aware of the problems
lurking in that area. I didn't think that was the point of the
discussion, but now that you bring it up it makes a lot more sense why
we have a communication gap.

To address your concern (without an example for now):
- Abstracting the difference between autonumber / identity and
sequences has been done by numerous frameworks, including Oracle's
TOPLink.

- The concurrency issue is a hard one and attempts to "genericize"
concurrency models will fail to take advantage of the Oracle's key
feature. I'm not advocating anything of the sort. If you build a
custom app, it should take advantage of the concurrency model of your
database, and it will be hell to port it to another database platform.

However, one can certainly reason about how to build code that works
with different database's concurrency models - but this will be more
complex, take more time, and money, and should only be invested by an
absolute business need to support mulitple databases. Most business
people, when presented with the cost, will balk. The exception is
vendors, who arguably shouldn't balk - but thus far, they have - to
the detriment of their installations.
Post by Daniel Morgan
So the response while impressive is unsatisfactory in that it didn't
address the issue. And the stuff about Project Marvel ... as marvelous
as it may be ... has nothing to do with the back-end database ...
HTML_DB is a front-end tool. Could I impose upon you to try again this
time addressing this issues around transaction processing.
Perhaps my clarification above will help. I am not arguing about
portability, I am arguing about tradeoffs among overlapping product
feature sets. I wrote the page on
http://c2.com/cgi/wiki?DesignForPerformance - I fully agree that once
you pick a database's concurrency model, you're going to have a bitch
of a time porting your isolation and transactional assumptions to fit
a different database's model. It's not impossible, but there is no
quick "generic" fix.

Cheers
Stu
Adam Jenkins
2004-01-29 21:29:22 UTC
Permalink
Post by Daniel Morgan
We are going to have to end this one with a total disagreement. Having
spent more than 33 years in IT and more than 15 of them with relational
"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance, and
scalability (and other stuff)"
and
"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"
What you suggest is a logical impossibility.
Perhaps your having spent 33 years in IT prevents you from actually
considering what someone else writes on the subject. Joe isn't actually
advocating either "complete DBMS dependance" or "complete DBMS
independance", as you seem to think, he's just defining the two
extremes. Then he goes on to explain some of the pros and cons of
different compromises between the two extremes. I don't see why you
keep bringing up this straw man of complete DBMS independance and
resulting terrible performance; noone in this thread is advocating that.

As I understand your argument, you're saying that since it's not
possible to write *completely* DBMS independant code without losing a
lot of performance and robustness offered by proprietary features, the
whole idea of DBMS independance is nonsense. A more reasonable approach
is to have DBMS independance as an ideal, but to recognize that gains in
performance and robustness can be had by using some proprietary and/or
non-universally supported DBMS features. So you take into account the
advantages of using a certain non-standard feature, and weigh it against
the extra cost of supporting it on the different DBMSes that you want to
support. Then you wrap the non-portable functionality that you decide
to use in an integration layer which needs to be reimplemented for each
DBMS. This is similar to the approach used for graphics APIs,
filesystems, network protocols, etc.

Adam
Daniel Morgan
2004-01-30 00:23:10 UTC
Permalink
Post by Adam Jenkins
Post by Daniel Morgan
We are going to have to end this one with a total disagreement. Having
spent more than 33 years in IT and more than 15 of them with
"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance,
and scalability (and other stuff)"
and
"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"
What you suggest is a logical impossibility.
Perhaps your having spent 33 years in IT prevents you from actually
considering what someone else writes on the subject. Joe isn't actually
advocating either "complete DBMS dependance" or "complete DBMS
independance", as you seem to think, he's just defining the two
extremes. Then he goes on to explain some of the pros and cons of
different compromises between the two extremes. I don't see why you
keep bringing up this straw man of complete DBMS independance and
resulting terrible performance; noone in this thread is advocating that.
As I understand your argument, you're saying that since it's not
possible to write *completely* DBMS independant code without losing a
lot of performance and robustness offered by proprietary features, the
whole idea of DBMS independance is nonsense. A more reasonable approach
is to have DBMS independance as an ideal, but to recognize that gains in
performance and robustness can be had by using some proprietary and/or
non-universally supported DBMS features. So you take into account the
advantages of using a certain non-standard feature, and weigh it against
the extra cost of supporting it on the different DBMSes that you want to
support. Then you wrap the non-portable functionality that you decide
to use in an integration layer which needs to be reimplemented for each
DBMS. This is similar to the approach used for graphics APIs,
filesystems, network protocols, etc.
Adam
All of this fluff, and I don't mean it in a prejorative way provides no
guideline. How would you make the decision as to which proprietary
features such as packages and sequences you would use and which ones not
to use.

Not once have I ever had a design spec. that said do a mediocre job of
implementing security, scalability, and performance.

Statements like "then you wrap the non-portable functionality that you
decide to use in an integration layer" are, from where I sit more fluff.
How do you write a wrapper around using a sequence versus using an
autonumbered column? I don't think it is technically possible.

I don't know you but strongly suspect your expertise is all front-end
... Java ... and that you really have substantial database experience.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Joe Weinstein
2004-01-29 16:51:19 UTC
Permalink
Post by Daniel Morgan
We are going to have to end this one with a total disagreement. Having
spent more than 33 years in IT and more than 15 of them with relational
"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance, and
scalability (and other stuff)"
I can't understand your inability to grok this. If a product is written
using DBMS-vendor-specific functionality in a way which makes the product
unportable to another DBMS, it is DBMS-specific and dependent on that DBMS.
Post by Daniel Morgan
and
"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"
A simple-minded product that connected to any JDBC-accessible DBMS, and
sent only fresh SQL queries is an example. Not powerful but certainly
DBMS-vendor independent.
Post by Daniel Morgan
What you suggest is a logical impossibility.
How did I do this time? What logical failure is there in my simple examples
above?
Post by Daniel Morgan
In Oracle, for example, there is no better place to put code than in a
package; for numerous reasons. No other database vendor has the concept
... therefore throw packages away.
In Oracle and DB2 the best way to do numering is with a sequence. SQL
Server and Sybase don't have them so throw sequences away. Of course SQL
Server and Sybase have autonumbering that Oracle doesn't have so throw
autonumbering away too. Guess we won't have any surrogate keys except by
wrapping your own ... now that's generic. All we need to do now is
recompile for every operating system.
No! You seem to be working on false presumptions. Repeating ad nauseum, I
advise against complete DBMS-independence. Using oracle packages would not
impose a severe enough problem with the generality of the DBMS client part
of the application for me to suggest that they not be used. If you need
numbering, you have to do it DBMS-specifically, or wrap your own. I don't
understand about the recompile comment. Java, for instance doesn't need it.
The other point is that there *are* some things that you should not have the
DBMS do. The reason may be that the functionality requires too much
specificity in the product outside the DBMS, or it may be simply be because
the part of the product outside the DBMS can do it better.
Post by Daniel Morgan
Sorry Joe ... but your attempt to construe development to sell your
company's product is a great way to do some things. Creating high
performance scalable databases isn't one of them. Not once has Oracle
won a benchmark contest with BEA using generic code. No one else will
either.
No one ever stated that the current best practice is generic code. You
are busily beating a horse that only you brought to the race. The big
point you can't address, is that even using all Oracle's capabilities,
generic or proprietary, it goes into standard benchmarks with middleware
to make it go fast. This means that there are some things you don't want
the DBMS to do whether they are generic or not. Even if some of these
things are usually thought of as central or integral to a generic DBMS
product.
Proof:
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all
Daniel Morgan
2004-02-01 21:42:32 UTC
Permalink
Post by Joe Weinstein
Post by Daniel Morgan
We are going to have to end this one with a total disagreement. Having
spent more than 33 years in IT and more than 15 of them with
"Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
specific functions that optimize or implement security, performance,
and scalability (and other stuff)"
I can't understand your inability to grok this. If a product is written
using DBMS-vendor-specific functionality in a way which makes the product
unportable to another DBMS, it is DBMS-specific and dependent on that DBMS.
Agreed.
Post by Joe Weinstein
Post by Daniel Morgan
"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"
Agreed.
Post by Joe Weinstein
A simple-minded product that connected to any JDBC-accessible DBMS, and
sent only fresh SQL queries is an example. Not powerful but certainly
DBMS-vendor independent.
Everytime someone disputes my point-of-view they do so with examples
that don't involve transactions. My challenge to you, made as blatantly
obvious as an unwashed purple rhinoceros in the middle of a living room
has involved 'sequences' for a reason. Anyone can come up with a
vendor-neutral select statement. I am challenging you to deal with
transactions and locking.
Post by Joe Weinstein
Post by Daniel Morgan
What you suggest is a logical impossibility.
How did I do this time? What logical failure is there in my simple examples
above?
As I've said so many times and I am beginning to wonder if I need to
SCREAM it ... you, and others that have agreed with you, have not once
responded with a transaction ... only with read-only SELECT statements.

Now perhaps it is just me ... but every time I connect a relational
database to a web front-end I expect it to be able to insert, update,
and delete ... not just select. I expect it to be able to create new
records, to lock records, to commit and rollback. Is my usage that unusual?

If you agree that a N-tier application should be able to create insert,
update, and delete, transactions ... then explain to me how you can be
vendor neutral and WITH THE SAME CODE handle Oracle with multi-version
conurrency (readers don't block writers and writers don't block readers)
and also support other RDBMS implementations? Same goes for sequences
vs. autonumbering columns. What are you goint to wrap this in?

Sure you can write your own table and increment a value in serial
fashion ... but that's not using native functionality. That's returning
to technoloogy I implemented back in the 1970s.
Post by Joe Weinstein
No! You seem to be working on false presumptions. Repeating ad nauseum, I
advise against complete DBMS-independence.
I repeat it because so far it has not been addressed except in read-only
examples involving select statements.

Using oracle packages would not
Post by Joe Weinstein
impose a severe enough problem with the generality of the DBMS client part
of the application for me to suggest that they not be used.
But as packages don't exist in any other RDBMS implementation the
front-end would need to be recoded. Agreed?

If you need
Post by Joe Weinstein
numbering, you have to do it DBMS-specifically, or wrap your own.
At which point you are 100% vendor dependent. Any wrap-your-own will
create serialization which greatly limits scalability. Agreed?
Post by Joe Weinstein
The reason may be that the functionality requires too much
specificity in the product outside the DBMS, or it may be simply be because
the part of the product outside the DBMS can do it better.
If anything can be done better outside the DBMS then I agree that
doesn't belong in the DBMS except as it may be required to guarantee
security and integrity if someone accesses the data with another tool.
Agreed?

I am not a database bigot. I put functionality in the front-end, in
middle tiers, anywhere that it makes sense. The issue from my standpoint
is not where functionality resides ... on that we are basically in
agreement.

My dispute is with the thought that I can be both vendor neutral and
vendor dependant. You can not have your cake and eat it too.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
***@x.washington.edu
(replace 'x' with a 'u' to reply)
Alfredo Novoa
2004-01-26 17:18:49 UTC
Permalink
Post by s***@yahoo.com
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.
Post by s***@yahoo.com
, 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
Vladimir Andreev
2004-01-30 16:25:48 UTC
Permalink
Post by s***@yahoo.com
There is NOTHING in a middle-tier that couldn't be done by a DBMS
There is, Sybrand. Connection pooling, for one. Just the other day I
saw a database that was serving hundreds of logins per minute. Guess
what kind of queries popped on the top of my StatsPack report?
Recursive SQL. Pure overhead.

Flado
Galen Boyer
2004-01-21 15:39:05 UTC
Permalink
Post by Joe Weinstein
Post by Daniel Morgan
The 'lets push more bytes down the pipe and across all those
routers' thinking is not going to lead to performance. You may
be scalable but performance will suffer. And you will be no
more scalable than a thinner client.
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.
Post by Joe Weinstein
and this can be intelligently and profitably done. Performance
and scalability follow, according to the non- volatility of the
data,
Can you explain further?
Post by Joe Weinstein
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.
Post by Joe Weinstein
Post by Daniel Morgan
Render under to database everything you can do in the database
and let the middle tier do what it does best ... fail-over,
load levelling, and serving up the front-end.
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?
Post by Joe Weinstein
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.
--
Galen Boyer
Alfredo Novoa
2004-01-26 17:07:47 UTC
Permalink
Post by Joe Weinstein
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.
Post by Joe Weinstein
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
JEDIDIAH
2004-06-24 20:58:45 UTC
Permalink
["Followup-To:" header set to comp.database.oracle.]
Post by Daniel Morgan
Post by Joe Weinstein
However, that dbms-specific level should be as narrow and
controllable/switchable
as possible. J2EE standards help there.
Joe
Post by Daniel Roy
Just my 2 cents
Daniel
I appreciate your opinion and your honesty that your perspective comes
from selling that middle tier but I completely disagree.
The 'lets push more bytes down the pipe and across all those routers'
thinking is not going to lead to performance. You may be scalable but
performance will suffer. And you will be no more scalable than a thinner
client.
Render under to database everything you can do in the database and let
the middle tier do what it does best ... fail-over, load levelling, and
serving up the front-end.
You are painting with far too broad a brush. Some of your examples below
represent absurd examples of middle-tier database processing. They would
(and do) horrify anti-centrists as much as they do you. Some of them
demonstrate that even good ideas can be poorly implemented.
Post by Daniel Morgan
Try tuning all that rotten SQL coming from those fat front-ends sometime
and you will understand why those here that have experience with
PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.
--
The public has a right to free music. It's part of the bargain that
was originally made with musicians and publishers. It's time that the |||
debate was shifted to reflect that. Robber Barons and their Toadies / | \
are distracting us from the original facts of the situation.
Noons
2004-01-21 08:03:32 UTC
Permalink
Post by Daniel Roy
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database.
Hmmm, from the pure performance point of view that is usually
the case. But more needs to be said about that. If someone moves
a Java component into the database and that Java component
decides to retrieve the data to populate an internal object and
continues to apply methods to the object to ensure for example
referential integrity, the problem will still be there. It doesn't
just matter where the code is: the problem is also with the bad
object-relational mapping. Moving the code to the db is not
gonna solve that one.

The techniques for efficient storage and manipulation of data were
investigated ages ago and have been perfected over the last 30 years of
database technology. There is NOTHING that Java can add to that or
the OO model can improve on that subject. However, the OO-design
proponents insist and persist on ignoring the entire edifice of IT
already existant and do things their own way.
The result is a monumental impedance mismatch with no solution until
more rsponsible people are put in charge of these OO-based projects.
Post by Daniel Roy
Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
almost all the code (including referential integrity!) in the middle
tier.
There is worse. I know of one that decided to create its own
indexing structures and keep them inside a table as a BLOB.
So that they'd remain portable and "efficient"...
Post by Daniel Roy
As a result, on ALL the projects I've been a part of, we have
had data issues. The worst part is for the foreign keys which are not
valid.
I'm surprised you only got data issues. You'd also have appaling
performance on any significant volume of data. That seems to
be the constant on all these products with an internal design
decided by group hug...
Post by Daniel Roy
objects/columns which don't exist anymore, ...). Also, performance is
always better from inside the database, from what I've seen so far.
By a very large factor. Orders of magnitude better in fact if the
object-relational mapping is properly done.
Post by Daniel Roy
This is logical since there is less network traffic when everything is
done from Oracle.
Caching could prevent that, but like someone else pointed out
the problem is with cache synchronization. A BIG one. Oracle has
a thing called cache-fusion that is supposed to solve that problem. But
it didn't catch on that much with the 3rd-party brigade.


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.
Most unfortunate.

Cheers
Nuno Souto
***@yahoo.com.au
Joel Garry
2004-01-21 18:31:56 UTC
Permalink
Post by Noons
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
--
@home.com is bogus.
"...musical food poisoning." - ad for American Idol
Noons
2004-01-21 09:01:18 UTC
Permalink
Post by Daniel Roy
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database.
Hmmm, from the pure performance point of view that is usually
the case. But more needs to be said about that. If someone moves
a Java component into the database and that Java component
decides to retrieve the data to populate an internal object and
continues to apply methods to the object to ensure for example
referential integrity, the problem will still be there. It doesn't
just matter where the code is: the problem is also with the bad
object-relational mapping. Moving the code to the db is not
gonna solve that one.

The techniques for efficient storage and manipulation of data were
investigated ages ago and have been perfected over the last 30 years of
database technology. There is NOTHING that Java can add to that or
the OO model can improve on that subject. However, the OO-design
proponents insist and persist on ignoring the entire edifice of IT
already existant and do things their own way.
The result is a monumental impedance mismatch with no solution until
more rsponsible people are put in charge of these OO-based projects.
Post by Daniel Roy
Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
almost all the code (including referential integrity!) in the middle
tier.
There is worse. I know of one that decided to create its own
indexing structures and keep them inside a table as a BLOB.
So that they'd remain portable and "efficient"...
Post by Daniel Roy
As a result, on ALL the projects I've been a part of, we have
had data issues. The worst part is for the foreign keys which are not
valid.
I'm surprised you only got data issues. You'd also have appaling
performance on any significant volume of data. That seems to
be the constant on all these products with an internal design
decided by group hug...
Post by Daniel Roy
objects/columns which don't exist anymore, ...). Also, performance is
always better from inside the database, from what I've seen so far.
By a very large factor. Orders of magnitude better in fact if the
object-relational mapping is properly done.
Post by Daniel Roy
This is logical since there is less network traffic when everything is
done from Oracle.
Caching could prevent that, but like someone else pointed out
the problem is with cache synchronization. A BIG one. Oracle has
a thing called cache-fusion that is supposed to solve that problem. But
it didn't catch on that much with the 3rd-party brigade.


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.
Most unfortunate.

Cheers
Nuno Souto
***@yahoo.com.au
BarryNL
2004-01-21 15:35:15 UTC
Permalink
Post by Noons
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.
Post by Noons
Most unfortunate.
Cheers
Nuno Souto
JEDIDIAH
2004-06-24 20:55:26 UTC
Permalink
["Followup-To:" header set to comp.database.oracle.]
Post by Daniel Roy
Hi Joe,
I am a Siebel configurator/programmer (Siebel is a "Customer
Relationship Management" software, which can be considered analogous
to SAP). My personal experience with the issue which interests you is
that as much as possible should be stored in the database. Siebel, by
some twisted reasoning about compatibility of code on various
databases (it runs on Oracle, SQL Server and DB2), decided to keep
That's just plain silly. Given that all of those products are variants
on a single specification based on SQL, the DDL is the least likely
part of these products to present cross-platform development issues.
Niggling quirks with datatypes (like date/time) are going to be far
more interesting.

My last project involved a product that was ported from msSQL to Oracle
(and then back) with another DB2 port in progress. Outside of stored
procedures, it was pretty simple to use perl to convert an Oracle schema
into something suitable for msSQL.

[deletia]
Jim Kennedy
2004-01-20 06:32:16 UTC
Permalink
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Joe,
I want to make a subtle distinction. Just about any database can store code
in a the database. (binary object) That said I think you mean more that
complex business logic can be stored and run in the database or server end
(eg in Oracle pl/sql or Java). Having the business logic (not the GUI
logic) in the database allows one to switch GUIs or have multiple systems
interact with the backend and consistant business rules are followed.
Having it in the middle tier means that every other system has to go through
that middle tier. Which means that other groups will go right to the
database and not through the middle tier.(time constraints, must do it now,
can't wait to use middle tier, middle tier written in a language we don't
like or don't know....)

Siebel, Peoplesoft et al hire programmers and not really dbas. Programmers
drive the projects and dbas are relagated to a lower importance. Thus these
products don't use Referential integrity, stored procedures etc. For an
example, in Siebel you "have to define all database objects through their
tool even indexes". Unfortunately, that means you can't create a Function
based index or an index where one of the elements of the key is descending
instead of the default ascending. Dumb, just dumb.

Jim
Joe
2004-01-23 17:23:00 UTC
Permalink
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
Post by Joe
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided
with
Post by Joe
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best
practices
Post by Joe
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Joe,
I want to make a subtle distinction. Just about any database can store code
in a the database. (binary object) That said I think you mean more that
complex business logic can be stored and run in the database or server end
(eg in Oracle pl/sql or Java). Having the business logic (not the GUI
logic) in the database allows one to switch GUIs or have multiple systems
interact with the backend and consistant business rules are followed.
Having it in the middle tier means that every other system has to go through
that middle tier. Which means that other groups will go right to the
database and not through the middle tier.(time constraints, must do it now,
can't wait to use middle tier, middle tier written in a language we don't
like or don't know....)
Siebel, Peoplesoft et al hire programmers and not really dbas.
Programmers
Post by Joe
drive the projects and dbas are relagated to a lower importance. Thus these
products don't use Referential integrity, stored procedures etc. For an
example, in Siebel you "have to define all database objects through their
tool even indexes". Unfortunately, that means you can't create a Function
based index or an index where one of the elements of the key is descending
instead of the default ascending. Dumb, just dumb.
Jim
Jim Kennedy
2004-01-24 04:34:59 UTC
Permalink
Post by 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
Post by Joe
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided
with
Post by Joe
a pretty revolutionary idea for a database product - namely the
ability
Post by Joe
to
Post by Joe
Post by Joe
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures
in
Post by Joe
Post by Joe
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best
practices
Post by Joe
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with
me
Post by Joe
on
Post by Joe
Post by Joe
the subject.
Thank you
Joe Lax
Joe,
I want to make a subtle distinction. Just about any database can store
code
Post by Joe
in a the database. (binary object) That said I think you mean more that
complex business logic can be stored and run in the database or server end
(eg in Oracle pl/sql or Java). Having the business logic (not the GUI
logic) in the database allows one to switch GUIs or have multiple systems
interact with the backend and consistant business rules are followed.
Having it in the middle tier means that every other system has to go
through
Post by Joe
that middle tier. Which means that other groups will go right to the
database and not through the middle tier.(time constraints, must do it
now,
Post by Joe
can't wait to use middle tier, middle tier written in a language we don't
like or don't know....)
Siebel, Peoplesoft et al hire programmers and not really dbas.
Programmers
Post by Joe
drive the projects and dbas are relagated to a lower importance. Thus
these
Post by Joe
products don't use Referential integrity, stored procedures etc. For an
example, in Siebel you "have to define all database objects through their
tool even indexes". Unfortunately, that means you can't create a Function
based index or an index where one of the elements of the key is descending
instead of the default ascending. Dumb, just dumb.
Jim
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
Joe Weinstein
2004-01-19 16:58:06 UTC
Permalink
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
Hi. My 2 cents: It's more of a reactionary idea rather than a revolutionary one.
The market growth and functionality growth since the early 90's has been in the
middle tier. The internet killed client-server, which was actually dead when the
DBMS vendors, even in benchmarking their products in the standard and artificially
DBMS-focussed TPC-C tests, began needing/using a real middle tier transaction
monitor/processor to get the maximum out of their DBMS. They continue to do this
today, and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo. (My interest
becomes apparent).
Productivity during development requires the new tools, standards and languages.
However, that's not enough. If you really want Enterprise-class applications
with the performance to handle the unlimited user base that the internet has
provided us, you would be misled to be seduced back to a DBMS-as-center-of-the-
universe architecture. The DBMS vendors would like this, but the fact is that
the DBMS already has enough work on it's plate doing the core ACID transactions.
It operates in a crucial but expensive isolation model that you don't want to
waste on catalog browsers. Think of a restaurant, and the DBMS as the chef.
If you want to scale beyond the 6-stool beanery, the customers don't interact
as-a-rule directly with the chef. There is an efficient middle tier of waitresses
to concentrate 'chef-access' to a few high-volume channels. Furthermore, for the
percentage of frequently-requested items, there is an independent cache which
the chef fills asynchronously, and the waitresses tap this cache to serve customers
without ever involving the DBMS except to occasionally say "Gravy's out!".
If you want to get to "Millions served" you would be wise to develop a
powerful independent middle tier to do all it can to serve those millions, and
to control/optimise the load on, and output of the DBMS. Lastly, consider the
world where transactions involve more than one independent resource. Customers
nowadays tend to want the best of everything with one click of a mouse. This is
like a catered wedding where she wants the soup from "Chez Fancy", and the canapes
from "Chin's Canape Castle". You really need that caterer guy with the funny
accent as an independent middle tier to handle the logistics to make it one
transaction.
Render unto Caeser (the DBMS) that (only) which is Caeser's. Sure, do your
heavy data grinding where the data is, in the DBMS. You build your saw mills
where the trees are, but: Let's say you're in Guam, and you want a box of
toothpicks and a dining room table. It is silly to call the Great North West Mill
for logs, but it is also silly to call the Great North West Mill for the toothpicks
and table. Something smart and independent in the middle, like www.walmart.com
is where the money, efficiency and solution is.

Joe Weinstein at BEA
Post by Joe
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
Andrew Carruthers
2004-01-20 19:06:44 UTC
Permalink
I'm afraid your case is not proven.

Cache syncronisation has got to be one of the biggest problems middleware
faces, most large organisations have data feeds directly into and out of the
DBMS, this data needs to appear in the middleware cache at some point, so
there is either a constant refresh cycle ocurring to renew data or the
middleware cache become out of date pretty quickly, thus negating the
preceived benefit. Why cache what is already cached in the DBMS? having 2
places to cache data is not the best architectural model I have ever seen
implemented, in fact, it's one of the dumbest.

Logic should reside as close to the data as possible, in fact, data should
be protected via API's to reduce the security risk, the only logic that
should reside in the middle tier is the glue to piece together the API's to
implement business rules - so long as there's more than one datastore
involved, for a single datastore the logic should always reside with the
data.

My second biggest problem with middleware is with vendors who put all their
logic, referential integrity and validation into middleware as if their
application is the only one of importance within an organisation and
everyone will conform to their rules and methods of working. This approach
works fine if the vendor is developing a stand-alone application but in the
real world I have yet to see a stand alone application which has no
connection to data feeds of one form or another. Implementing applications
is more about integrating them into systems and this is where middleware
orientated applications fail most often.
Post by Joe Weinstein
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
Hi. My 2 cents: It's more of a reactionary idea rather than a
revolutionary one.
Post by Joe Weinstein
The market growth and functionality growth since the early 90's has been in the
middle tier. The internet killed client-server, which was actually dead when the
DBMS vendors, even in benchmarking their products in the standard and artificially
DBMS-focussed TPC-C tests, began needing/using a real middle tier transaction
monitor/processor to get the maximum out of their DBMS. They continue to do this
today, and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo. (My interest
becomes apparent).
Productivity during development requires the new tools, standards and languages.
However, that's not enough. If you really want Enterprise-class applications
with the performance to handle the unlimited user base that the internet has
provided us, you would be misled to be seduced back to a
DBMS-as-center-of-the-
Post by Joe Weinstein
universe architecture. The DBMS vendors would like this, but the fact is that
the DBMS already has enough work on it's plate doing the core ACID transactions.
It operates in a crucial but expensive isolation model that you don't want to
waste on catalog browsers. Think of a restaurant, and the DBMS as the chef.
If you want to scale beyond the 6-stool beanery, the customers don't interact
as-a-rule directly with the chef. There is an efficient middle tier of waitresses
to concentrate 'chef-access' to a few high-volume channels. Furthermore, for the
percentage of frequently-requested items, there is an independent cache which
the chef fills asynchronously, and the waitresses tap this cache to serve customers
without ever involving the DBMS except to occasionally say "Gravy's out!".
If you want to get to "Millions served" you would be wise to develop a
powerful independent middle tier to do all it can to serve those millions, and
to control/optimise the load on, and output of the DBMS. Lastly, consider the
world where transactions involve more than one independent resource. Customers
nowadays tend to want the best of everything with one click of a mouse. This is
like a catered wedding where she wants the soup from "Chez Fancy", and the canapes
from "Chin's Canape Castle". You really need that caterer guy with the funny
accent as an independent middle tier to handle the logistics to make it one
transaction.
Render unto Caeser (the DBMS) that (only) which is Caeser's. Sure, do your
heavy data grinding where the data is, in the DBMS. You build your saw mills
where the trees are, but: Let's say you're in Guam, and you want a box of
toothpicks and a dining room table. It is silly to call the Great North West Mill
for logs, but it is also silly to call the Great North West Mill for the toothpicks
and table. Something smart and independent in the middle, like
www.walmart.com
Post by Joe Weinstein
is where the money, efficiency and solution is.
Joe Weinstein at BEA
Post by Joe
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Thank you
Joe Lax
HK
2004-01-20 20:06:01 UTC
Permalink
Post by Andrew Carruthers
Logic should reside as close to the data as possible
It looks like BEA documentation agrees with you:

http://edocs.bea.com/wls/docs81/jdbc/performance.html#1025805

IMHO, you should code where you feel most comfortable. This does not
mean doing data integrity checks in the middleware app. That should
always be done in the DB.
Joe Weinstein
2004-01-20 21:49:24 UTC
Permalink
References: <Y7IOb.20178$***@nwrddc01.gnilink.net> <***@bea.com> <***@corp.supernews.com> <JSfPb.2378$***@newssvr26.news.prodigy.com>
In-Reply-To: <JSfPb.2378$***@newssvr26.news.prodigy.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 216.148.48.12
X-Trace: news.beasys.com 1074635456 216.148.48.12 (20 Jan 2004 13:50:56 -0800)
Organization: BEA SYSTEMS Inc
Lines: 23
Path: intern1.nntp.aus1.giganews.com!internal1.nntp.ash.giganews.com!border2.nntp.ash.giganews.com!border1.nntp.ash.giganews.com!nntp.giganews.com!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!news.beasys.com!not-for-mail
Xref: intern1.nntp.aus1.giganews.com comp.database.oracle:16819 comp.databases.oracle.server:282726 comp.databases.oracle.tools:96117 comp.lang.java.databases:61461 comp.lang.java.programmer:688752
Post by HK
Post by Andrew Carruthers
Logic should reside as close to the data as possible
http://edocs.bea.com/wls/docs81/jdbc/performance.html#1025805
IMHO, you should code where you feel most comfortable. This does not
mean doing data integrity checks in the middleware app. That should
always be done in the DB.
I agree with you and the doc. (I wrote it ;-) ). That shouldn't conflict with
data caching, nor business rules/logic where the cache is. That documentation
refers to JDBC programming, to prevent row-by-row raw data retrieval to
clients in Java to do dumb iterative, non-set-based processing, like I described
in the payroll application that was converted to 4 pipelined stored procedures.

Joe
Joe Weinstein
2004-01-20 19:57:02 UTC
Permalink
Post by Andrew Carruthers
I'm afraid your case is not proven.
Hi! Thanks. 'Proven' needs a definition, but if there exist many large
enterprises with worldwide distributed applications in successful service,
then they at least stand as support for the case...
Post by Andrew Carruthers
Cache syncronisation has got to be one of the biggest problems middleware
faces, most large organisations have data feeds directly into and out of the
DBMS, this data needs to appear in the middleware cache at some point, so
there is either a constant refresh cycle ocurring to renew data or the
middleware cache become out of date pretty quickly, thus negating the
preceived benefit. Why cache what is already cached in the DBMS? having 2
places to cache data is not the best architectural model I have ever seen
implemented, in fact, it's one of the dumbest.
The virtue of caching data is as described, making it available in a lighter, faster
way than if the DBMS must be consulted. The refresh of cache benefits from it's being
not necessarily synchronous with user requests. This architecture allows for varying
transactional isolation as a user interaction wends its way unpredictably from a browse
mode to a possible binding transaction. You want to limit the strict costly centralized
ACID transaction part to the final DBMS-involved part. The speed benefit of having
customers all over the globe perusing a locally cached catalog is worth the occasional
retry necessary when they commit a purchase that fails because the DBMS changed relevantly
since the cache was updated.
Cache synchronization is an issue, but so is DBMS synchronization. One is more
costly than the other, based on the guarantees it is designed to provide. The point is
that the user experience defines a 'session/transaction' that lends itself to a varying
level of concurrency-vs-isolation, and intelligent distributed caches provide the
desired spectrum.
Post by Andrew Carruthers
Logic should reside as close to the data as possible,
I agree, but some of this data can be cached, with logic in/around a fast intelligent
cache that resides between the millions of users and the very busy DBMS(s).
Post by Andrew Carruthers
in fact, data should
be protected via API's to reduce the security risk,
Always true...
Post by Andrew Carruthers
the only logic that
should reside in the middle tier is the glue to piece together the API's to
implement business rules - so long as there's more than one datastore
involved, for a single datastore the logic should always reside with the
data.
Unless/until one sees the value of cached data. Not raw cached data, but
an intelligent middle tier.
Post by Andrew Carruthers
My second biggest problem with middleware is with vendors who put all their
logic, referential integrity and validation into middleware as if their
application is the only one of importance within an organisation and
everyone will conform to their rules and methods of working.
I agree. Simple non-volatile referential integrity constraints should certainly
be in the DBMS. It is a mistake to treat the DBMS as a dumb generically replaceable
file system. However, this criticism of yours can also be applied to the DBMS-biassed,
who think that all the logic needs to be in the DBMS, and that everyone must conform
to DBMS ways of working...
Post by Andrew Carruthers
This approach
works fine if the vendor is developing a stand-alone application but in the
real world I have yet to see a stand alone application which has no
connection to data feeds of one form or another. Implementing applications
is more about integrating them into systems and this is where middleware
orientated applications fail most often.
Interesting! I see mor often that middleware exists to integrate applications into
unified internet-wide access, and integrating multiple standalone DBMSes. Integration
is hard. This is where middleware succeeds as well as fails (GIGO). However, I wouldn't
put the job of integration of applications to {the/one of the} DBMS(s).
Joe
Post by Andrew Carruthers
Post by Joe Weinstein
Post by Joe
Hi -
Over the last several versions of Oracle, developers have been provided
with
Post by Joe Weinstein
Post by Joe
a pretty revolutionary idea for a database product - namely the ability
to
Post by Joe Weinstein
Post by Joe
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures
in
Post by Joe Weinstein
Post by Joe
Java.
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
Hi. My 2 cents: It's more of a reactionary idea rather than a
revolutionary one.
Post by Joe Weinstein
The market growth and functionality growth since the early 90's has
been in the
Post by Joe Weinstein
middle tier. The internet killed client-server, which was actually dead
when the
Post by Joe Weinstein
DBMS vendors, even in benchmarking their products in the standard and
artificially
Post by Joe Weinstein
DBMS-focussed TPC-C tests, began needing/using a real middle tier
transaction
Post by Joe Weinstein
monitor/processor to get the maximum out of their DBMS. They continue to
do this
Post by Joe Weinstein
today, and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo.
(My interest
Post by Joe Weinstein
becomes apparent).
Productivity during development requires the new tools, standards and
languages.
Post by Joe Weinstein
However, that's not enough. If you really want Enterprise-class
applications
Post by Joe Weinstein
with the performance to handle the unlimited user base that the internet
has
Post by Joe Weinstein
provided us, you would be misled to be seduced back to a
DBMS-as-center-of-the-
Post by Joe Weinstein
universe architecture. The DBMS vendors would like this, but the fact is
that
Post by Joe Weinstein
the DBMS already has enough work on it's plate doing the core ACID
transactions.
Post by Joe Weinstein
It operates in a crucial but expensive isolation model that you don't want
to
Post by Joe Weinstein
waste on catalog browsers. Think of a restaurant, and the DBMS as the
chef.
Post by Joe Weinstein
If you want to scale beyond the 6-stool beanery, the customers don't
interact
Post by Joe Weinstein
as-a-rule directly with the chef. There is an efficient middle tier of
waitresses
Post by Joe Weinstein
to concentrate 'chef-access' to a few high-volume channels. Furthermore,
for the
Post by Joe Weinstein
percentage of frequently-requested items, there is an independent cache
which
Post by Joe Weinstein
the chef fills asynchronously, and the waitresses tap this cache to serve
customers
Post by Joe Weinstein
without ever involving the DBMS except to occasionally say "Gravy's out!".
If you want to get to "Millions served" you would be wise to develop a
powerful independent middle tier to do all it can to serve those millions,
and
Post by Joe Weinstein
to control/optimise the load on, and output of the DBMS. Lastly, consider
the
Post by Joe Weinstein
world where transactions involve more than one independent resource.
Customers
Post by Joe Weinstein
nowadays tend to want the best of everything with one click of a mouse.
This is
Post by Joe Weinstein
like a catered wedding where she wants the soup from "Chez Fancy", and the
canapes
Post by Joe Weinstein
from "Chin's Canape Castle". You really need that caterer guy with the
funny
Post by Joe Weinstein
accent as an independent middle tier to handle the logistics to make it
one
Post by Joe Weinstein
transaction.
Render unto Caeser (the DBMS) that (only) which is Caeser's. Sure, do
your
Post by Joe Weinstein
heavy data grinding where the data is, in the DBMS. You build your saw
mills
Post by Joe Weinstein
where the trees are, but: Let's say you're in Guam, and you want a box of
toothpicks and a dining room table. It is silly to call the Great North
West Mill
Post by Joe Weinstein
for logs, but it is also silly to call the Great North West Mill for the
toothpicks
Post by Joe Weinstein
and table. Something smart and independent in the middle, like
www.walmart.com
Post by Joe Weinstein
is where the money, efficiency and solution is.
Joe Weinstein at BEA
Post by Joe
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best
practices
Post by Joe Weinstein
Post by Joe
on the subject, and possibly publishing an article on the topic.
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me
on
Post by Joe Weinstein
Post by Joe
the subject.
Thank you
Joe Lax
Noons
2004-01-21 07:40:27 UTC
Permalink
Post by Joe
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
You gotta be joking! A "revolutionary idea"? Where the heck have
you been in the last 15 years??? It's only been possible in Oracle
since about 1990 or thereabouts... Oh yes, Java is NOT the only way
to code, in case you haven't noticed.

For starters: there is NO such thing as "code that used to belong
in the middle tier"! That is an invention of middle tier vendors
that has NEVER been proven as valid in real application. Code NEVER
belonged in the middle tier until the concept of multi tier was invented,
about 6 or 7 years ago.
Post by Joe
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
Amazing! Must be breakneck technology. Pity it's been done by just
about any other serious database vendor for the last 10 years...
But I'm quite sure now that M$ is jumping on the bandwagon, it will
suddenly become a credible "industry standard" to store code in the
database. Oh yeah, they've been able to do so with Transact-SQL
for ages but what the hey...
Post by Joe
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
Do a search on comp.databases.oracle.server for "design" and "J2EE".
Then read.
Post by Joe
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Like I said: search on c.d.o.s.

Cheers
Nuno Souto
***@yahoo.com.au.nospam
Joe
2004-01-23 17:29:27 UTC
Permalink
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
Post by Noons
Post by Joe
Over the last several versions of Oracle, developers have been provided with
a pretty revolutionary idea for a database product - namely the ability to
write code that used to belong in the middle tier and store it in the
database. I'm referring here to the ability to write stored procedures in
Java.
You gotta be joking! A "revolutionary idea"? Where the heck have
you been in the last 15 years??? It's only been possible in Oracle
since about 1990 or thereabouts... Oh yes, Java is NOT the only way
to code, in case you haven't noticed.
For starters: there is NO such thing as "code that used to belong
in the middle tier"! That is an invention of middle tier vendors
that has NEVER been proven as valid in real application. Code NEVER
belonged in the middle tier until the concept of multi tier was invented,
about 6 or 7 years ago.
Post by Joe
Now of course, Microsoft with their SQL Server product is doing the same
thing. The next version of SQL Server will allow programmers to write
stored procedures in any of the .NET languages.
Amazing! Must be breakneck technology. Pity it's been done by just
about any other serious database vendor for the last 10 years...
But I'm quite sure now that M$ is jumping on the bandwagon, it will
suddenly become a credible "industry standard" to store code in the
database. Oh yeah, they've been able to do so with Transact-SQL
for ages but what the hey...
Post by Joe
I'm interested in looking at the increased choices developers now have
because of these new features in more depth ,developing some best practices
on the subject, and possibly publishing an article on the topic.
Do a search on comp.databases.oracle.server for "design" and "J2EE".
Then read.
Post by Joe
I personally am more experienced with SQL Server than with Oracle. I am
therefore looking for someone who has been involved with making these
choices in the Oracle environment who would like to collaborate with me on
the subject.
Like I said: search on c.d.o.s.
Cheers
Nuno Souto
Continue reading on narkive:
Loading...