Re: Flamewar object databases vs. relational databases (was: Unknown SQL)

>> >My point:
>> >If you program with Java, you can use our database without knowing
 anything
>> >about relational systems.
>>
>> My point:
>> If you program with Java, you can use a relational database with greater
>> productivity and flexibility, and without limiting access to Java (just
 in
>> case).
>
>There are many researchers that have proved that mapping objects to
>relational databases consumes between 20 to 50% of the development work.

Those researchers clearly did not have a clue what they were talking about. Classes already map directly to domains with no effort required.

>Scott Ambler has written an excellent paper on this theme
>http://www.ambysoft.com/mappingObjects.html

How can anyone consider a paper full of misinformation and regurgitated pap excellent?

>Object databases reduce the mapping work to zero.

I have already explained several times how relational databases reduce the mapping to zero. Object Classes = Domains. Done.

>Accordingly you can reach higher productivity by 20 to 50%.

Since no effort was required in the first place, you can never reach higher productivity than relational. Or does your solution require negative effort?

>> >> >Relational databases map classes to tables
>> >> >no matter how many unnecessary
>> >> >in-between layers you invent.
>> >
>> >You do have objects on one side and tables somewhere on the other don't
>> you?
>>
>> Huh? I have objects on both sides. Some in tables and some in program
>> variables.
>
>Are you trying to bring up Lee's implementation of serializing objects to
>columns?

Nope. I am talking about full support for user-defined data types. Since your assumption is false, all of your subsequent points are irrelevant.

>-This is unsuitable in practice, since
>- it is totally rigid.

Your point is irrelevant. See above.

>- Class changes are not possible

Your point is irrelevant. See above.

>- does not keep track of possible multiple instantiation of the same object

When you say "object", do you mean object variable or object value? The information rule prevents multiple instantiation of two object values with the same identity. In any case, your point is irrelevant. See above.

>- needs instantiation of objects on the server side for queries

Your point is irrelevant. See above.

>- it will not allow to reinstantiate complex object networks

Your point is irrelevant. See above.

>- takes objects out of their context

Your point is irrelevant. See above.

>- does not conform to any standard

Your point is irrelevant. See above.

>- does not allow SQL queries on member fields of stored objects

Your point is irrelevant. See above. By the way, what does your product allow SQL queries on?

>Earlier you said "a value 10 always is a value 10 in a relational
 database".
>With the above approach it is not. A value 10 of a member of an object is
>serialized to an array of bytes.

...which is still a valid representation of the value 10. Even if were not, your point would be irrelevant. See above.

>So forget the above approach.

I never considered it in the first place. You could save yourself a lot of effort and embarassment by not trying to put words in my mouth.

>So we do have:

No. We don't have:

>- Objects on one side
>- Tables on the other
>- a mapping that must happen somewhere inbetween.

We have objects on one side, and objects on the other side. Object Classes = Domains.

>> >Don't come up with the ridiculous design of storing objects in
 relational
>> >columns as a counter-example. It is not used in practice and it provides
 no
>> >sensible querying mechanism.
>>
>> The intelligence of practitioners is not my fault. As for querying, it
>> provides the best querying mechanism. Your statement is again simply
>untrue.
>
>The querying mechanism is rigid and limited to the methods of the stored
>objects.

Again, your statement is simply untrue. Possibly, your assumptions are untrue.

>Since all objects need to be instantiated for querying

"Instantiation" is a strictly physical concept. The relational model does not limit implementations to those requiring "instantiation".

>the
>algorithm is very slow and resource consuming.

The relational model does not dictate any algorithm, any performance characteristic or any resource usage.

>Indices to improve execution
>can not be used.

Again, this is simply untrue. The relational model does not dictate whether or how to use indexes.

>> >With this blind decision they choose to spend 20 to 50% of their
>> >implementation work on mapping objects to tables.
>>
>> Well, if they choose to map objects to tables, that's their first
 mistake.
>> Object classes map to domains, dummy!
>
>Again:
>No matter how many inbetween layers there are, you have objects on one side
>and tables on the other.

Again, your statement is untrue. Object classes map directly to domains with no added layers or preservatives. We have objects on one side and objects on the other.

>> Actually, when dealing with relational DBMSs, arbitrary, nebulous,
>> conceptual decisions are solidified into sound correct solutions using
>> normalization.
>
>Actually when dealing with a clean class design

Please define "clean class design".

>there is no need for
>another representation in a different form that represents an old-fashioned
>paradigm.

Mathematics is old-fashioned? I know it's been around for a long time, but I never realized it fell out of fashion. What are we replacing it with? Phonics?

>Relational databases where designed before object-oriented
>languages were widely adopted.

Relational and objects have been contemporaries from day 1. Object classes map directly to domains, which have been an integral part of the relational model since 1969.

>No wonder they don't match.

More rhetorical horseshit. The don't match because third-generation object oriented languages are very low-level languages compared to relational languages.

Regards,
Bob Received on Sun Jul 22 2001 - 01:29:16 CEST