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

"Stu Charlton" <stuartc_at_mac.com> wrote in message news:21398ab6.0401300846.5bd8450d_at_posting.google.com...

> Well, it seems Nuno jumped ahead 2 weeks to where the thread would
> probably wind up ;)

Ooooh! sorry....
:)

> Very much so. O/R mapping has been evolving for over 10 years and
> it's only recently that you're starting to see a discipline emerging.

Exactly. I spent the last two and a half years involved in an Air Force project: we started from a perspective of "everything in the db" and as we progressed, we moved plenty off it. As we realized it made no sense to keep it in the db.

Part of the exercise involved rationalising what we did initially and apply whatever principles of O-R mapping we could find or identify that actually made sense.

There is a lot of material out there, but 90% of it is fluff:

• stuff that someone used in ONE project and is now "rule for all". Won't mention any names but some know exactly what I'm talking about...
• stuff that started from the "all in Java" and went the other way to make it work fast. With shortcuts galore and just plain incorrect ideas.
• stuff that just plain didn't make ANY sense.
• and finally, little bits and pieces that we could use and adapt and had a solid theoretical background.

There are some very interesting materials in OTN, Oracle magazine and Metalink, but you gotta dig deep! Cameron O'Rourke has written some of the best materials I've ever seen on this subject. Worth a read for those who may want to
get an idea of what I'm talking about. We based most of our design on some of his ideas and suggestions. The result was lightening fast and very, very efficient.
And easy to maintain as well!

> On the other hand, whenever I scratch a team re-inventing the wheel
> outside of the database, I find lurking underneath the classic
> "developer/DBA conflict", which is usually the fault of management for
> not properly defining roles and principles. This leads developers to
> use technical means to solve an IT management or interpersonal
> problem. Not to fault them of course, given the sorry state of
> 'management'.

100% agreed...

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam