Re: Where to find discussion of EJB vs Database

Hans Forbrich wrote:

> I'm looking for some rational discussion/links/books related to the thought
> and engineering behind the 'middleware object vs database entity/stored
> procedure' discussion.
>
> Everything I see is based on one of two premises:
> "[in our shop DBA is king and therefore] all goes into database"; or
> "[the Java developers are king and therefore] our business demands that
> nothing except the data goes into the database".
>
> The above arguments are generally based on lack of experience ("all I have
> is a hammer"), purely religious or emotional and are generally meaningless.
>
> What I need is some straight forward discussion that helps decide, in an
> open minded shop, what to look for or how to decide (eg: benchmarks) to
> find the proper mix of middle tier and database tier responsibility.
>
> This would include the arguments from the DB side of "enforcing business
> rules when people bypass the middle tier" as well as the arguments from the
> AS side of "smaller, portable machines for application scalability".
>
> Why: I'm tired of the "we need to be database independent" argument. I
> firmly believe that 100% database independence is nonsense:
>
> a) from a technical perspective - referring to the demonstrations in Tom
> Kyte's books should be sufficient argument;
>
> b) from a business perspective - if you buy Oracle database, then developing
> & maintaining one line of code duplicating Oracle's extended functionality
> is a serious waste of business resources. (Stick with MySQL or PostgreSQL
> if you just want a data bucket)
>
> Any pointers or links to supported arguments appreciated.
>
> TIA
> /Hans
> forbrich at remove_this dot telus planet dot net

No point in restating Tom Kyte's arguments as they are solid and stand on their own.

But here are a few thoughts of mine:

1. If you are developing an internal application database independence is meaningless. The app will not be moved to a different environment during the time the front-end and middle-tier(s) will exist. And if they are it demonstrates a tremendous lack of due diligence in selecting the original back-end database and platform.
2. The argument to put data integrity into the front-end is based on the totally irresponsible idea that no one will ever gain access to the database using some other tool. If there is nothing that guarantees the integrity of the data in the back-end the first person that connects with SQL*Plus, ODBC, TOAD, whatever, can destroy everything. And Murphy's law, and experience, teach that this is precisely what happens.
3. The main problem front-end developers (Java etc.) have with what is written into the back-end is their own ignorance: Teach them about the database.

I recently co-taught a JDeveloper class with a Java developer whose skills are excellent. Yet as good as his Java skills ... he couldn't figure out how to tell what sequences were used by what triggers. Didn't know about object-relational views. Didn't know about hundreds of basic things that would/could have made his job easier. His desire for control really came from a tremendous level of ignorance about the database.

4. Your data bucket idea has merit at a superficial level but not beyond that. A good database can provide many things even as a data bucket. Ability to recover from a crash. Ability to partition data. Abilities encapsulated in the DBMS and UTL packages. Security. Stability. And perhaps equally importantly ... someone on the other end of the wire when you phone support.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)