Re: Data access concepts

From: Alex Chudnovsky (chud73_at_dodo.com.au)
Date: 01/19/04


Date: Mon, 19 Jan 2004 16:00:57 GMT


> Why all this talk about
> converting the relational model to a object model. Make a object model
> for accessing the relational model instead!

A Relational Model is not Object Oriented it is Relational.
An Object Oriented Language is Object Oriented.

The key point that I am trying to make here is that an Object Model
programmatically Models the real life domain problem, that is the beauty of
Object Oriented languages they let you Model real life objects
programmatically.
By having an 'Object domain model' model the database instead of the actual
domain problem totally defeats the purpose.

Perhaps your talking about just an object oriented way of dealing with the
database that would make sense perhaps something along the lines of Ofbiz
entity engine, but what I get is that your implying that you model the
database programmatically and to me that makes little sense.

Regards,
Alex Chudnovsky.

"Fredrik Bertilsson" <fredrik_bertilsson@passagen.se> wrote in message
news:31f7e57d.0312280926.7e3119e0@posting.google.com...
> 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



Relevant Pages

  • Re: EJB - Why do we need java persistence on top of a database?
    ... Before you can use an SQL database for persistence, ... SQL stores fields. ... design in limited, primitive ways only. ... object model is not, ...
    (comp.lang.java.programmer)
  • Re: Binary Serialization
    ... I am trying to serialize a class and save it in a database. ... When you do that you lock away the data so that only your code can ever get to it, and you are bypassing all the data management features of SQL Server. ... Usually you will map your object model to a relational model, storing each object as a row in a table, with its fields broken out in columns. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: OO vs. RDB challenge
    ... > So nothing that would actually compare the object model to the ... The object model of data does not exist. ... > kinds of crap using non-scientific methods that doesn't prove anything. ...
    (comp.object)
  • Re: Databinding - Best Practice (object-oriented)
    ... >>relational model throughout your application severely restricts the ... The Relational Model is not SQL. ... difficult to persuade developers to ditch the database independance this ... What SQL domains should be but they are not. ...
    (microsoft.public.dotnet.framework.windowsforms.databinding)
  • Re: Databinding - Best Practice (object-oriented)
    ... >>relational model throughout your application severely restricts the ... The Relational Model is not SQL. ... difficult to persuade developers to ditch the database independance this ... What SQL domains should be but they are not. ...
    (microsoft.public.dotnet.framework.windowsforms)

Loading