Re: Mixing P/R philosophy with OO (within J2EE).

On Apr 17, 1:14 pm, Patrick May <p...@xxxxxxx> wrote:
Harry <simonsha...@xxxxxxxxx> writes:
On Apr 14, 6:16 pm, Patrick May <p...@xxxxxxx> wrote:
On April 7, 2007, Harry wrote:
My current understanding is that the RDBMS is a layer [ . . . ]
providing me a very valuable, a very significant service in terms
of something (set theory) that I'm well familar with since my
pre-college days. In absence of any multi-vendor-RDBMS support
requirement, I'd very much like my solution to be closest to this
layer.

You have yet to explain ...

You seem to fail to get the point again and again. That tells me
you're either plain dumb, or just pretending to not get it... in
either of which cases no one can really help.

why you'd like to always map your problem
domain model to a relational schema. You have also failed to explain
how RDBMSs being based on relational algebra translates to value in
real world problem domains.

Re-read this thread from the beginning, this time a little slowly.

In other words, you've got nothing. Thanks for playing.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
p...@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)

Hi,

I don't wish to join in on any personal battles but the OP asked some
very valid questions and although I don't share topmind's strong anti-
OO viewpoint I am truly thankful that he posts here because without
scrutiny and challenge we'll degenerate into a blind mutual back
patting society.

In my current role I was hired to make J2EE/Weblogic/Oracle run
faster.

I have observed the work of literally hundreds of Java developers.
From what I can see the notion that the database should be reduced to
a mere "persistence storage mechanism" has prevailed. Great.

1. The big problem is the more you treat a database like a black box
the more you damage performance and scalability. Sure you pass unit
tests, acceptance tests, even go into production for a while, all is
well, then bang!

The issue is not one or two bugs but the most insidious blunder I've
ever witnessed. This piece of morbidity lies dormant until it's way
too late.

Now, I do not wish to offend our beloved OO community but overly
simplistic abstractions are, I'm afraid to say, idiotic.

Dictionaries define idiotic as "irresponsibly insane".

Is is irresponsible to choose ignorance when knowledge is required.
Choosing so deliberately is insane or irrational. Thus idiotic.

Treating a database like a mere "persistence storage mechanisms" is on
par with the following abstractions:-
-Computer - a typewriter without the liquid paper,
-Wife - w)ashing, i)roning, f)ood and e)ntertainment,
-Airplane - just another transportation mechanism.

It seems obvious to sane people that these abstractions are literally
idiotic because they are overly simplistic but when it comes to
complex software like Oracle apparently that type of over
simplification is OK?


2. Pigs will fly before you need to change the database vendor. Yet a
strong vendor neutral approach was also taken "just in case".

Meantime, the clear and present danger with J2EE is bloat and schedule
blow out.

Vendor specific features that would have helped performance and
productivity, like stored procedures, sequence generators, date
manipulators, specialized indexes and certain locking and concurrency
features were avoided like the plague.

Yet we depend on Microsoft, Sun, BEA, IBM, Novell and a host of others
without question. What's wrong with Oracle?

Granted sometimes we must really be vendor neutral, I've had to do it
but it isn't as simple as using Hibernate and setting a flag. Every
database has surprising differences, even at the fundamental level!
And no, ANSI-SQL doesn't help one hoot.

3. Addressing some of the OP's questions.

Java and J2EE have some real winners and then some real big losers in
the object relational mapping field. A proverbial mine field.

a) JDBC - Never before in history were so many database API's
abstracted and unified with a relatively simple interface. Virtually
every database on the planet can now be accessed via JDBC. Yet you
still have enough control of the db to make it sing and dance. JDBC -
a winner.

Topmind, if you're reading this, isn't this a good example of OOP?

But that wasn't enough, people got greedy and wanted more, mind you
for less work. Sun obliges, or do they?

b) Entity Beans - bolted some botched persistence attempt onto their
*distributed* object API. Avoid!

c) EJB3 - finally split persistence off into JPA. Based on Hiberante,
Toplink, JDO and others. But I fear, as with Hibernate, the idiotic
"black box" mentally is only encouraged further. Thus making lazy
programmers even lazier.

* I recommend handwritten JDBC with a dash of simple RM friendly OOP
here and a pinch of helping procedure there. These should all be kept
in a separate layer and this is the only layer where mixing paradigms
is allowed. You can thus keep both the RM and OOP, or whatever else
you prefer, relatively happy.

If you care about scalability and performance then it pays to know how
your database actually operates. The more you know the more you will
succeed.

If you want productivity improvements then don't do everything the
long way in the name of neutrality. Don't worry you'll still get to
write lots of code, Java and C# are verbose enough more typing is the
last thing you need.

JDBC, "the original and still the best object-relational API", IMHO.

End rant.
Thanks for reading.

.

Relevant Pages

  • Stuff the purple heart programmers cook up
    ... C To act like a framework for the JDBC driver developers. ... D To hide the specifics of accessing particular kinds of database ... Topic: Java 2: Survey Author: Chris Mc Devitt ... The JDBC ResultSet is actually an interface java.sql.ResultSet. ...
    (comp.lang.java.programmer)
  • Re: What about a DBMS that wont be platform-specific
    ... This would be my first time doing this and the database is being ... There is no JDBC driver for Access. ... In Java, you can use databases which provide only ODBC drivers through the JDBC-ODBC ... Sun includes a JDBC-ODBC bridge with their standard distro, ...
    (comp.lang.java.databases)
  • Re: How to modify a MySQL database...
    ... and then update them with Java. ... To learn how to create a MySQL database, ... you will need to learn JDBC. ...
    (comp.lang.java.programmer)
  • Re: Overwriting a Access Database using JDBC
    ... >> I'm not familiar with JDBC, co I can't comment on the Java. ... >> The UPDATE statement will update every row in the database, ... CREATE TABLE foo ...
    (comp.lang.java.programmer)
  • Re: polymorphism (was: Poly Couples)
    ... but this is not really "business software"... ... Most of such applications are built as a combination of ... database with flat files or a different RDBMS vendor?" ... couldn't care less if I do it in using structured programming or OOP ...
    (comp.object)