Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Robert Martin wrote:
> Ah, it is so easy to generalize about what one person understands.
> Are you saying that it is "pure unadulterated garbage" that application
> developers should isolate their application code from the the whims of
> the API designers at Oracle?

Database API is SQL. Everything else is auxiliary technology that supports it. JDBC is merely a low level programmatic glue between SQL and Java, PL/SQL (stored procedures) are the way to enhance SQL with programmatic relations (aka functions).

> Should those application designers use
> every little cute ORACLE trick and call?

Sometimes you have no choice. Consider hierarchical queries, for example. Would you go through all the trouble learning/implementing nested sets/intervals, materialized path etc, or rather write relatively straightforward query based on proprietory "connect by" SQL feature?

> Or shoudl they stick to
> standard SQL as proferred by ODBMS or JDBMS, etc. Should those
> application developers scatter embedded SQL all through their
> application code?

This is a culprit that OO people stubbornly refuse to understand. Embedding high level language (SQL) statements inside low level language (Java) is perfectly reasonable. What you propose instead, a pathetic set of classes that build the query dynamically?

> Or should they partition that application code into
> areas that know about the DB and areas that don't? Should they strive
> to make it possible to swap Oracle for MySql or not?

Writing generic SQL might be a good idea, but sometimes you have to use proprietory feature. It saves time in a short term.

> Should they
> strive even to eliminate the relational flavor of the data from the
> guts of their algorithms, or not.

This is rethorical question.

        | Received on Wed May 31 2006 - 18:14:52 CEST