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

[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.

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

Thank you

Joe Lax

[Joe Weinstein]

Joe Lax wrote:
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
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 joelax@dbdirections.com Thank you Joe Lax

[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
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 joelax@dbdirections.com Thank you Joe Lax

[Joe Weinstein]

Daniel Roy wrote:
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
Just my 2 cents DanielHi -Over the last several versions of Oracle, developers have been provided witha pretty revolutionary idea for a database product - namely the ability towrite code that used to belong in the middle tier and store it in thedatabase. I'm referring here to the ability to write stored procedures inJava.Now of course, Microsoft with their SQL Server product is doing the samething. The next version of SQL Server will allow programmers to writestored procedures in any of the .NET languages.I'm interested in looking at the increased choices developers now havebecause of these new features in more depth ,developing some best practiceson the subject, and possibly publishing an article on the topic.I personally am more experienced with SQL Server than with Oracle. I amtherefore looking for someone who has been involved with making thesechoices in the Oracle environment who would like to collaborate with me onthe subject.If you are interested, please contact me at joelax@dbdirections.comThank youJoe Lax

[Jim Kennedy]

"Joe" <joelax@dbdirections.com> wrote in message
news:Y7IOb.20178$ko5.19870@nwrddc01.gnilink.net... 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 joelax@dbdirections.com 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

[Andrew Carruthers]

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.


"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message
news:400C0C9E.40107@bea.com... Joe Lax wrote: 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 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 joelax@dbdirections.com Thank you Joe Lax

[Joe Weinstein]

Andrew Carruthers wrote:
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...
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.
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).
in fact, data should be protected via API's to reduce the security risk,

Always true...
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.
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...
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
"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message news:400C0C9E.40107@bea.com...Joe Lax wrote:Hi -Over the last several versions of Oracle, developers have been provided witha pretty revolutionary idea for a database product - namely the ability towrite code that used to belong in the middle tier and store it in thedatabase. I'm referring here to the ability to write stored procedures inJava.Now of course, Microsoft with their SQL Server product is doing the samething. The next version of SQL Server will allow programmers to writestored 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 themiddle tier. The internet killed client-server, which was actually dead when theDBMS vendors, even in benchmarking their products in the standard and artificiallyDBMS-focussed TPC-C tests, began needing/using a real middle tier transactionmonitor/processor to get the maximum out of their DBMS. They continue to do thistoday, and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo. (My interestbecomes apparent). Productivity during development requires the new tools, standards and languages.However, that's not enough. If you really want Enterprise-class applicationswith the performance to handle the unlimited user base that the internet hasprovided 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 thatthe 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 towaste 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 interactas-a-rule directly with the chef. There is an efficient middle tier of waitressesto concentrate 'chef-access' to a few high-volume channels. Furthermore, for thepercentage of frequently-requested items, there is an independent cache whichthe chef fills asynchronously, and the waitresses tap this cache to serve customerswithout 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 apowerful independent middle tier to do all it can to serve those millions, andto control/optimise the load on, and output of the DBMS. Lastly, consider theworld where transactions involve more than one independent resource. Customersnowadays tend to want the best of everything with one click of a mouse. This islike a catered wedding where she wants the soup from "Chez Fancy", and the canapesfrom "Chin's Canape Castle". You really need that caterer guy with the funnyaccent as an independent middle tier to handle the logistics to make it onetransaction. Render unto Caeser (the DBMS) that (only) which is Caeser's. Sure, do yourheavy data grinding where the data is, in the DBMS. You build your saw millswhere the trees are, but: Let's say you're in Guam, and you want a box oftoothpicks and a dining room table. It is silly to call the Great North West Millfor logs, but it is also silly to call the Great North West Mill for the toothpicksand table. Something smart and independent in the middle, like www.walmart.comis where the money, efficiency and solution is.Joe Weinstein at BEAI'm interested in looking at the increased choices developers now havebecause of these new features in more depth ,developing some best practiceson the subject, and possibly publishing an article on the topic.I personally am more experienced with SQL Server than with Oracle. I amtherefore looking for someone who has been involved with making thesechoices in the Oracle environment who would like to collaborate with me onthe subject.If you are interested, please contact me at joelax@dbdirections.comThank youJoe Lax

[HK]

Andrew Carruthers wrote: 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.

[Daniel Morgan]

Joe Weinstein wrote:
However, that dbms-specific level should be as narrow and controllable/switchable as possible. J2EE standards help there. Joe 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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Joe Weinstein]

Daniel Morgan wrote:
Joe Weinstein wrote: However, that dbms-specific level should be as narrow and controllable/switchable as possible. J2EE standards help there. Joe 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.
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.
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.
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]

"Joe" <joelax@dbdirections.com> wrote in message news:<Y7IOb.20178$ko5.19870@nwrddc01.gnilink.net>...
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.

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

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.

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
wizofoz2k@yahoo.com.au.nospam

[Noons]

danielroy10junk@hotmail.com (Daniel Roy) wrote in message news:<3722db.0401191316.646fd135@posting.google.com>...
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.
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"...

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

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
wizofoz2k@yahoo.com.au

[Noons]

danielroy10junk@hotmail.com (Daniel Roy) wrote in message news:<3722db.0401191316.646fd135@posting.google.com>...
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.
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"...

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

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
wizofoz2k@yahoo.com.au

[Noons]

"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message news:400DC795.7070804@bea.com...
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...

(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
wizofoz2k@yahoo.com.au.nospam

[Daniel Morgan]

Joe Weinstein wrote: Daniel Morgan wrote: 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.
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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[BarryNL]

Noons wrote: danielroy10junk@hotmail.com (Daniel Roy) wrote in message news:<3722db.0401191316.646fd135@posting.google.com>... 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.
Most unfortunate. Cheers Nuno Souto wizofoz2k@yahoo.com.au

[Galen Boyer]

On Tue, 20 Jan 2004, joeNOSPAM@bea.com wrote: 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.
and this can be intelligently and profitably done. Performance and scalability follow, according to the non- volatility of the data,

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

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

[Joe Weinstein]

Daniel Morgan wrote:
Joe Weinstein wrote: Daniel Morgan wrote: 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.
We all know all RDBMS vendors do whatever they need to get the magic number ... the one better than the competition.

Sure, but the point is that middleware (which is used in exactly the same way
in the real world, not *just* for benchmarks) is crucial to get the best
performance out of a DBMS, even in a benchmark that is tailored specifically
to be DBMS-centric.
But all of what you refer to as "protecting the DBMS from uncontrolled ad-hoc connections" as middle-ware is not valid on its face. You put up the best middleware tool you can and then give me SQL*Plus, MS Access, whatever ... and all of your protections are null and void. The middleware only protects from those connections routed through the middleware ... and it is for that reason specifically we see far too much data corruption.

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

I agree, but would only add that there is need for *other* security and
integrity, and even for such things as transactional integrity, the multi-
resource nature of current state-of-the-business transactions requires
external transaction coordinators to guarantee that integrity.
That you may layer a little more on top is fine but anyone depending on it rather than the RDBMS is begging for problems.

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

[Joel Garry]

wizofoz2k@yahoo.com.au (Noons) wrote in message news:<73e20c6c.0401210003.a70d76c@posting.google.com>...
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

[Guest]

Joe Weinstein <joeNOSPAM@bea.com> wrote in message news:<400EB04E.1010101@bea.com>... 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]

sybrandb@yahoo.com wrote: Joe Weinstein <joeNOSPAM@bea.com> wrote in message news:<400EB04E.1010101@bea.com>...Depending on an external layer for what the DBMS is best at, *is* beggingfor 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, inperformance to start.To repeat the inarguable example, the DBMS can't even do the basic job it wasdesigned 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 wouldprobably agree for the most part on specific functionality that should be inthe 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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Joe Weinstein]

sybrandb@yahoo.com wrote:
Joe Weinstein <joeNOSPAM@bea.com> wrote in message news:<400EB04E.1010101@bea.com>...Depending on an external layer for what the DBMS is best at, *is* beggingfor 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, inperformance to start.To repeat the inarguable example, the DBMS can't even do the basic job it wasdesigned 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 wouldprobably agree for the most part on specific functionality that should be inthe 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.
I have seen NO (I repeat NO) middle-tier applications that couldn't be qualified as a complete DRAMA. Anyone with only a little bit of experience in the field is aware of that.

What you say is true, but those with more than a little experience in the
field may differ... ;)
There is NOTHING in a middle-tier that couldn't be done by a DBMS, in most cases having it done by a middle-tier 'application' is at it's best asking for something completely unscalable (which BTW everyone with a little bit of experience knows).

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

I guess I'm more of a blasphemer and infidel? ;)
if you really are a 'DBMS guy' you wouldn't have made your completely erroneous claim 'depending on a DBMS is begging for problems'

Misquote renoted. The point is that I'm not *only* a DBMS guy. My specialty
(since '96) is Java-database connectivity (JDBC). BEA (weblogic) developed
the first JDBC drivers for Oracle, Sybase, Informix, and MS SQLServer. Before
that, for 8 years I was joe@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... ;)
Depending on a middle-tier however IS, as everyone knows, BEGGING for problems, especially when being used by inexperienced developers (and middle-tier 'applications' are ONLY being developed by inexperienced developers) Sybrand Bakker Senior Oracle DBA

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

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

Joe Weinstein at BEA

[Joe]

Jim -

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks

Joe Lax
joelax@dbdirections.com



"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:QX3Pb.103910$8H.177187@attbi_s03... "Joe" <joelax@dbdirections.com> wrote in message news:Y7IOb.20178$ko5.19870@nwrddc01.gnilink.net... 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 joelax@dbdirections.com 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]

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


"Noons" <wizofoz2k@yahoo.com.au> wrote in message
news:73e20c6c.0401202340.70ffcb6f@posting.google.com... "Joe" <joelax@dbdirections.com> wrote in message
news:<Y7IOb.20178$ko5.19870@nwrddc01.gnilink.net>... 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. 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... 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. 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 wizofoz2k@yahoo.com.au.nospam

[Niall Litchfield]

<sybrandb@yahoo.com> wrote in message
news:a1d154f4.0401220423.2c4ea885@posting.google.com... Joe Weinstein <joeNOSPAM@bea.com> wrote in message
news:<400EB04E.1010101@bea.com>... 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
******************************************

[Chris Uppal]

Joe Weinstein wrote:
There is NOTHING in a middle-tier that couldn't be done by a DBMS, in most cases having it done by a middle-tier 'application' is at it's best asking for something completely unscalable (which BTW everyone with a little bit of experience knows). Again, [snip] I believe that the audience that believes that there should be no middle tier, and that having the DBMS do everything is more scaleable, is small and preferentially populated by your group of 'everyone with a little bit of experience'.

Oooh, ooh! Lovely!

-- chris

[Jim Kennedy]

"Joe" <joelax@dbdirections.com> wrote in message
news:ULcQb.466$KU5.37@nwrddc02.gnilink.net... 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 joelax@dbdirections.com "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message news:QX3Pb.103910$8H.177187@attbi_s03... "Joe" <joelax@dbdirections.com> wrote in message news:Y7IOb.20178$ko5.19870@nwrddc01.gnilink.net... 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 joelax@dbdirections.com 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,
Put the RI and business rules in the database. Anything that has to do with
maintaining data integrity and related matters goes in the database. For
Oracle, I would use pl/sql where that fits the best and use Java where that
fits best. This gives you great flexibility to allow a whole plethora of
applications written in whatever the business thinks is best to write them
in. (Java, Cobol, APL, Fortran, C, whatever) This also means you can have
client server, web based applications, multi-tiered apps, etc. all
accrssing the same database and one set of business rules applying to all of
them. This does not mean that those applications can't have logic in them,
(eg edit rules, format rules, just the database will enforce those rules.)
By putting the business rules in the database allows one point of QA for all
those applications from a data point of view. (data consistency)

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


Jim

[Noons]

"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message news:40100718.3070108@bea.com...
I wish you well, but this seems so parochial as to be comical! I suspect that you don't *want* to know about the success and need for middleware, as if it threatened the Papacy of DBAs. I'll bet the chance you'll visit the BEA site and examine the immense customer list of global company success stories is nill, but as others might, here's a link: http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/customers


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

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

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

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

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

--
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

[Joe Weinstein]

Noons wrote:
"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message news:40100718.3070108@bea.com...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 andneed for middleware, as if it threatened the Papacy of DBAs.I'll bet the chance you'll visit the BEA site and examine theimmense customer list of global company success stories is nill,but as others might, here's a link:http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/customers Joe, the notion that DBA's are somehow "popes" is today old hat. It's an old TCO argument from the Microslop mob. Proven false ages ago. DBA's nowadays are simply trained monkeys nursing third party apps. And little else. And have been so for years.

Well, I have more respect for them than that... And the strident
oppinions some of them have may have to do with doing hard, complicated
work which is often under-appreciated. It is also true that the
bulk of problems with these third-party apps would not exist if they
had been written with 1/10th the DBMS understanding that the DBA has.
Customer success stories in web sites? Come on! Do you expect that to impress someone? A little old lady maybe?

I *never* said Sybrand is a little old lady! ;) But to be serious,
even though some sites content is as trustable as those "As seen on TV"
avertisements, BEA is posting big and referenceable successes.
The question is not if BEA has a good middleware engine. There is no doubt in my mind it does. Probably the best.

You are a gentleman and a scholar Sir. If we succeed in returning this
thread to the topic of 'where should we put logic and/or data?', I would
be interested to hear your opinion on the affirmative value of middleware.
It seems that, even when Oracle itself is asked to show how fast and scale-
able it's DBMS is, Oracle says "OK! Watch what we can do with BEA's
transaction monitor!", some other DBMS-biased still say "It's the DBMS, stupid".
The question is how much of and what kind of code should be in that middle tier. Which has got nothing to do with your experience at Sybase/BEA, mine at IBM/Univac/Prime/Oracle/world or the price of fish in fact. Or rather: it has everything to do with it. It's based on experience with prior environments and technology that we can hope to make proper decisions regarding which is the best way to go.

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

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

[Joe Weinstein]

Hi Niall!

Niall Litchfield wrote:
<sybrandb@yahoo.com> wrote in message news:a1d154f4.0401220423.2c4ea885@posting.google.com...Joe Weinstein <joeNOSPAM@bea.com> wrote in message news:<400EB04E.1010101@bea.com>...Depending on an external layer for what the DBMS is best at, *is* beggingfor 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, inperformance to start.To repeat the inarguable example, the DBMS can't even do the basic job it wasdesigned 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 wouldprobably agree for the most part on specific functionality that should be inthe DBMS.Joe Weinstein at BEAApparently you have been brainwashed and consider middle-tier to beTHE Gospel, and now you are trying to brainwash others. Your assertion'depending on the DBMS is begging for problems' demonstrates thatclearly: you simply don't know what you are talking about. I have seenNO (I repeat NO) middle-tier applications that couldn't be qualifiedas a complete DRAMA. Anyone with only a little bit of experience inthe field is aware of that.There is NOTHING in a middle-tier that couldn't be done by a DBMS, inmost cases having it done by a middle-tier 'application' is at it'sbest asking for something completely unscalable (which BTW everyonewith 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.
The app server guys have a *lot* of arguing to do with me around the case for database independence and middle tier data validation etc,

Sure! *I* tend to council against complete DBMS independence. This is not
for love or preference for a given DBMS product, but in acknowledgement
that a significant portion of the DBMSes capabilities are presented in a
proprietary way. As to data validation, I believe that there is a wide
spectrum of viable data validity, and it balances with concurrency. Middleware
provides for an architecture that gives a wide-and-finely tuneable way to
choose how much concurrency vs. currency is wanted.
ISTM that this approach is purely in the interest of app developers, but not in the interest of good design and application owners and users. Equally arguing that the database can and should do everything seems equally mad.

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

On Sat, 24 Jan 2004 21:03:39 +1100, "Noons"
<wizofoz2k@yahoo.com.au.nospam> wrote:
The question is how much of and what kind of code should be in thatmiddle tier.

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

--
Mike Sherrill
Information Management Systems

[Daniel Morgan]

Mike Sherrill wrote:
On Sat, 24 Jan 2004 21:03:39 +1100, "Noons" <wizofoz2k@yahoo.com.au.nospam> wrote:The question is how much of and what kind of code should be in thatmiddle 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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Noons]

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

--
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nspam
"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message
news:4012BC90.7080103@bea.com... 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

[Daniel Morgan]

Joe Weinstein wrote:
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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Andrey]

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1075098515.457142@yasure... Joe Weinstein wrote: 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]

Andrey wrote:
"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1075098515.457142@yasure...Joe Weinstein wrote:Sure! *I* tend to council against complete DBMS independence. This is notfor love or preference for a given DBMS product, but in acknowledgementthat a significant portion of the DBMSes capabilities are presented in aproprietary way.What you are counselling is that people write some of the worst possiblecode and NOT take advantage of those features and capabilities that makea product worth the money.And just because at some point years later they MIGHT decide to changeto another product where they can once again write mediocre code withminimal performance and scalability.On one hand you toot BEA's horn by saying the Oracle gets its bestperformance with BEA. Then you advise removing the beast's teeth and claws.Sounds a bit schizophrenic to me. Buy my product because it makes Oracleblazingly fast ... but when you implement it ... don't take advantage ofany 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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Andrey]

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1075109383.391383@yasure... Andrey wrote: "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1075098515.457142@yasure...Joe Weinstein wrote:>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 possiblecode and NOT take advantage of those features and capabilities that makea product worth the money.And just because at some point years later they MIGHT decide to changeto another product where they can once again write mediocre code withminimal performance and scalability.On one hand you toot BEA's horn by saying the Oracle gets its bestperformance with BEA. Then you advise removing the beast's teeth and claws.Sounds a bit schizophrenic to me. Buy my product because it makes Oracleblazingly fast ... but when you implement it ... don't take advantage ofany 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.

[Stu Charlton]

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1075098515.457142@yasure>... Joe Weinstein wrote: 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

[Guest]

"Andrey" <adm@mlm.ru> wrote in message news:<bv2ni7$rh3$1@gavrilo.mtu.ru>... "Daniel Morgan" <damorgan@x.washington.edu> wrote in message 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

[Daniel Morgan]

Andrey wrote:
"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1075109383.391383@yasure...Andrey wrote:"Daniel Morgan" <damorgan@x.washington.edu> wrote in messagenews:1075098515.457142@yasure...>Joe Weinstein wrote:>>>>>Sure! *I* tend to council against complete DBMS independence. This isnot>>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 andclaws.>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 isgroundless.Try not to jump into the middle of a conversation without reviewing itfrom the beginning. Not one of my sentences has referred to Oracle'smiddle ware. We have been discussing BEA's and its use in Oracle's TPCbenchmarks. 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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

Stu Charlton wrote:
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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

[Joe Weinstein]

Daniel Morgan wrote:
Joe Weinstein wrote: 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.
And just because at some point years later they MIGHT decide to change to another product where they can once again write mediocre code with minimal performance and scalability. On one hand you toot BEA's horn by saying the Oracle gets its best performance with BEA. Then you advise removing the beast's teeth and claws. Sounds a bit schizophrenic to me. Buy my product because it makes Oracle blazingly fast ... but when you implement it ... don't take advantage of any of those features that make it blazingly fast.

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

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

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

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

[Alfredo Novoa]

Joe Weinstein <joeNOSPAM@bea.com> wrote in message
Well, I actually want thin clients, but from DBMS perspective, the application server is not a thin client.

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

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


Regards
Alfredo

[Joe Weinstein]

Daniel Morgan wrote:

Hi Daniel. I hope my other response was clear, and this one of yours is clearer
than your first.
You either fully embrace a software and leverage it for all of its scalability, security, and performance features or you are leaving money on the table.

Only in a simple one-vendor environment. If you are using more than one product,
both may offer some same bit of functionality, and perhaps you cannot use them
redundantly, but must choose one or other. In this case, the money you paid
one of the vendors for the feature is already lost. You will presumably choose
to use the one that either works best, or provides some side benefit.
The word "complete" has no value. How should it be interpreted ... Use 78.2% of the features but not all? Maybe only 74.5%. I know he used the word ... but it provides not a single bit of clarity. It still translates to "don't take maximum advantage of proprietary features".

Let me make it clearer. It should be clear and obvious that the simple bank+tellers
OLTP benchmark in TPC-C can, and has been completely implemented with Oracle software.
In that configuration, Oracle's features, proprietary or not, have been used to their
utmost. However, when the stopwatch meets the marketing department, it appears that
Oracle did it's best by leaving some existing oracle functionality on the table, and
going so far as pay for some outside replacement functionality.
Therefore, the percentage you seek, 78.2% or 74.5% (or 3