Data access concepts

• Previous message: Paul L: "Connection Problem JDBC"
• Next in thread: brougham5_at_yahoo.com: "Re: Data access concepts"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 28 Dec 2003 09:26:28 -0800

I have spend some time to investigate the different concepts of
O/R-mapping, JDO and entity beans (EJB) for accessing relational
databases in java programming. I may be very conservative, but I can't
see that these tools reduces the time that have to be spent on doing
database programming. Of course, when you do SQL coding in the old
fashion way, you have to spend a lot of time doing simple insert,
update and select statements. But the other concepts adds extra things
to do or reduces the power of SQL.

Most O/R-mapping tools forces you to write both database DML, java
value objects and mapping descriptors. And mostly it introduces a
query language that is similar to SQL, but still something else, and a
accepted standard is missing. Why must java classes and tables be
mapped? Why can't java classes be generated from the database
structure?

JDO has not the concepts of relations (correct me if I am wrong) and
the query language seem to be very poor. When I look at the JDO API, I
miss most things that are good with relational databases. And I see
that I am not the first one to reject JDO.

It is a well known fact that entity beans (EJB) have a poor
performance and they don't reduces the time spent on writing SQL
statements, very much. Your either have to write JDBC calls (BMP) or
write SQL (or SQL-like) statemenents in descriptor files (CMP).

What I am missing is a object model on top of JDBC that reduces the
time you have to spend on simple SQL statements, but still gives you
the power to write complex queries. Why are there not a well-known API
that have Table class with the method findByPrimaryKey? This method
could return a instance of a Record class, with get- and set-methods,
and a save-method. With this a lot of boring work could be reduced. If
preferred, subclasses of this Record class could be generated for
every table, for making type-safe get- and set-methods.

In addition you should also have a Query class for expressing more
complex queries. All tools I have seen (except of S.O.D.A) uses
strings for defining query filters. Why?? It would be very simple to
make a Query object model for expressing a complex SQL select
statement.

Maybe I am the last one that thinks that the databases is an important
part of an application. And that the relational model is the
state-of-art concept of modeling data. Why all this talk about
converting the relational model to a object model. Make a object model
for accessing the relational model instead!

I have made a prototype on how a object model on top of the relational
model could look like (http://butler.sourceforge.net). Take a look if
you agree with me in the views above.

/Fredrik Bertilsson

• Previous message: Paul L: "Connection Problem JDBC"
• Next in thread: brougham5_at_yahoo.com: "Re: Data access concepts"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]