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

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

> First let me say you have my admiration. You put in effort and made an
> attempt at answering my query. But the problem is that your example very
> carefully, perhpas even artfully, dodged the issue I put in front of you
> like a charging rhinoceros. What I asked was "please provide an example
> of how you could use PACKAGES and SEQUENCES in Oracle and meet your
> stated objective" ... and you didn't.

You're right. It wasn't intentional, I just wanted to whip something up relatively quickly.

> 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.

We can get into that if you'd like, but I'm well aware of the problems lurking in that area. I didn't think that was the point of the discussion, but now that you bring it up it makes a lot more sense why we have a communication gap.

To address your concern (without an example for now): - Abstracting the difference between autonumber / identity and sequences has been done by numerous frameworks, including Oracle's TOPLink.

• The concurrency issue is a hard one and attempts to "genericize" concurrency models will fail to take advantage of the Oracle's key feature. I'm not advocating anything of the sort. If you build a custom app, it should take advantage of the concurrency model of your database, and it will be hell to port it to another database platform.

However, one can certainly reason about how to build code that works with different database's concurrency models - but this will be more complex, take more time, and money, and should only be invested by an absolute business need to support mulitple databases. Most business people, when presented with the cost, will balk. The exception is vendors, who arguably shouldn't balk - but thus far, they have - to the detriment of their installations.

> 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.

Perhaps my clarification above will help. I am not arguing about portability, I am arguing about tradeoffs among overlapping product feature sets. I wrote the page on
http://c2.com/cgi/wiki?DesignForPerformance - I fully agree that once you pick a database's concurrency model, you're going to have a bitch of a time porting your isolation and transactional assumptions to fit a different database's model. It's not impossible, but there is no quick "generic" fix.

Cheers
Stu Received on Fri Jan 30 2004 - 11:03:02 CST