Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: choices regarding where to place code - in the database or middletier

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

From: Joe Weinstein <joeNOSPAM_at_bea.com>
Date: Fri, 30 Jan 2004 08:42:47 -0800
Message-ID: <401a8980@news.beasys.com>


Daniel Morgan wrote:

> Noons wrote:
>

>> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
>> news:1075442171.779310_at_yasure...
>>
>> Sorry folks, I'm reducing the number of x-posts otherwise my ISP will 
>> kill
>> my replies: thank God ONE provider is taking an active stance against
>> spam on Usenet, I say!
>>
>>
>>
>>> By selecting as your example: "A web-page that displays" you eliminated
>>> anything having to do with sequences. What I was trying to get you to
>>> deal with was issues related to insert, update, and delete. Issues that
>>> involve sequences but also the transaction and locking models that are
>>> totally different between commercial database products.
>>>
>>> So the response while impressive is unsatisfactory in that it didn't
>>> address the issue. And the stuff about Project Marvel ... as marvelous
>>> as it may be ... has nothing to do with the back-end database ...
>>> HTML_DB is a front-end tool. Could I impose upon you to try again this
>>> time addressing this issues around transaction processing.
>>>
>>
>>
>> I can see your point. But I think you are approaching it from the wrong
>> angle.
>> The whole argument about wrappers is precisely to hide an implementation
>> from a design requirement.
>>
>> The concern is not if one database has a sequence and another has an auto
>> sequence column.
>>
>> The (design) concern is: I want a surrogate key on EVERY relational row
>> storing my object data and an ID for my persistent object instance data.
>> Period.

>
>
> I understand and agree. I've used wrappers many times myself.
>
> But at some point you have got to step up to the plate and put that code
> into a package or use a sequence to generate that surrogate key.
>
> And when you do everything from that point on down is vendor specific.
> It is not going to be implemented against any other vendor's product
> without a rewrite.
>
> So does the wrapper allow you to implement a single front-end against
> multiple back-ends ... absolutely ... and your explanation was great.
> But you are still hand-coding at some point against a specific RDBMS.
>
> So lets go back to the original discussion that started off between
> myself and Joe. Joe works for BEA and was advocating what I took to be a
> bit of schizophrenia ... dependence and independence.

Hi. Yes, you did misunderstand, and I'm glad it's cleared up, and thanks to Nuno and Stu for the contributions. As you can see, an application can (and as I have always suggested, should) use DBMS-specific code in cases where it offers major benefits. However, the application is well served to isolate DBMS-specific code to a wrapper layer, making the bulk of the application DBMS-neutral if possible. Further, I am just pointing out that even within the DBMS-specific layer, or just above that at the application's hopefully generic DBMS API layer, there may well be some DBMS functionality (whether generic or DBMS-specific) that an application may be better served to not use, and rely instead on an implementation in middleware. (Joins on tabular data is *not* an example ;) ). An example of such functionality is having middleware multiplex between a wide-ranging fluctuating population of ad-hoc application users and the DBMS by maintaining and optimally using a small dedicated well-used shared set of DBMS connections, instead of allowing every application user to create an independent DBMS connection for every user session. Another example is in the trivial caching of non-volatile data so the DBMS is not harried with 100,000 identical queries per day for a list of the countries in Europe. Transaction monitoring/control is another, amply proven by all currently competitive TPC benchmarks. This defines a grey scale of dependence/independence, which should be useful in clearing up any remaining cognitive dissonance.

Joe Weinstein at BEA Received on Fri Jan 30 2004 - 10:42:47 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US