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

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_at_dbdirections.com
> Thank you
> Joe Lax
Received on Mon Jan 19 2004 - 10:58:06 CST