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.

[Quoted]      The market growth and functionality growth since the early 90's has been in the [Quoted] middle tier. The internet killed client-server, which was actually dead when the [Quoted] DBMS vendors, even in benchmarking their products in the standard and artificially [Quoted] DBMS-focussed TPC-C tests, began needing/using a real middle tier transaction [Quoted] monitor/processor to get the maximum out of their DBMS. They continue to do this [Quoted] today, and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo. (My interest [Quoted] becomes apparent).

    Productivity during development requires the new tools, standards and languages. [Quoted] However, that's not enough. If you really want Enterprise-class applications [Quoted] with the performance to handle the unlimited user base that the internet has [Quoted] provided us, you would be misled to be seduced back to a DBMS-as-center-of-the- [Quoted] universe architecture. The DBMS vendors would like this, but the fact is that [Quoted] the DBMS already has enough work on it's plate doing the core ACID transactions. [Quoted] It operates in a crucial but expensive isolation model that you don't want to [Quoted] waste on catalog browsers. Think of a restaurant, and the DBMS as the chef. [Quoted] If you want to scale beyond the 6-stool beanery, the customers don't interact [Quoted] as-a-rule directly with the chef. There is an efficient middle tier of waitresses [Quoted] to concentrate 'chef-access' to a few high-volume channels. Furthermore, for the [Quoted] percentage of frequently-requested items, there is an independent cache which [Quoted] the chef fills asynchronously, and the waitresses tap this cache to serve customers [Quoted] 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 [Quoted] to control/optimise the load on, and output of the DBMS. Lastly, consider the [Quoted] world where transactions involve more than one independent resource. Customers [Quoted] nowadays tend to want the best of everything with one click of a mouse. This is [Quoted] like a catered wedding where she wants the soup from "Chez Fancy", and the canapes [Quoted] from "Chin's Canape Castle". You really need that caterer guy with the funny [Quoted] accent as an independent middle tier to handle the logistics to make it one transaction.

[Quoted]     Render unto Caeser (the DBMS) that (only) which is Caeser's. Sure, do your [Quoted] heavy data grinding where the data is, in the DBMS. You build your saw mills [Quoted] 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 [Quoted] for logs, but it is also silly to call the Great North West Mill for the toothpicks [Quoted] and table. Something smart and independent in the middle, like www.walmart.com [Quoted] 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 - 17:58:06 CET