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

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1075365124.32752_at_yasure>...

> "Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
> specific functions that optimize or implement security, performance, and
> scalability (and other stuff)"
>
> and
>
> "Complete DBMS independence means that a system is not bound to a given
> DBMS, because it uses only the functionality offered by the DBMS that is
> accessible via DBMS-neutral syntax"
>
> What you suggest is a logical impossibility.

I think I understand completely what Joe is trying to say, so I doubt it is a logical impossibliity. I suggest it's a communications gap.  

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

That's not the suggestion at all. Packages are good things and should be used in any case you have stored procedures.

> In Oracle and DB2 the best way to do numering is with a sequence. SQL
> Server and Sybase don't have them so throw sequences away. Of course SQL

Again, that's not the case. Keep your sequences.

> Sorry Joe ... but your attempt to construe development to sell your
> company's product is a great way to do some things. Creating high
> performance scalable databases isn't one of them. Not once has Oracle
> won a benchmark contest with BEA using generic code. No one else will
> either.

I think the point is not about generic vs. specific code. Genericity is a trade-off against performance, and isn't always applicable.

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

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

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

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

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

Cheers
Stu Received on Thu Jan 29 2004 - 12:49:51 CST