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

From: Stu Charlton (stuartc_at_mac.com)
Date: 01/29/04 

Date: 29 Jan 2004 10:49:51 -0800

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

Relevant Pages