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

>> What is the rhetoric? Your product limits its use to people who know
 Java.
>> In order to use your product, one must learn Java. If one must learn a
>> language to use a product, one will learn a simpler language faster. As
>> you correctly point out, the more redundant "concepts" one has to learn,
>> the greater the effort.
>>
>>
>> >Should I post a website link, that uses our database as a backend?
>>
>> Who cares? We already know that Java programmers can build websites.
>
>If you use the website, you are using our database.

Not true. I am using the website. The programmer who writes the website uses your product.

>> Nope. My argument is you need to understand C to write C programs. You
>> need to understand Java to write Java programs. You need to know the
>> DBMS data model to query the data. Teaching a user about a single
 concept,
>> call it relation or table or whatever, is easier than teaching users the
 differences
>> between Array, Set, Bag and Collection.
>
>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).

>> >Relational databases map classes to tables
>>
>> No, they don't. The statement is simply untrue. Relational databases map
>> classes to domains. As I mentioned before, if you took any time to
 educate
>> yourself, you would already know this.
>>
>>
>> >no matter how many unnecessary
>> >in-between layers you invent.
>>
>> Since the supporting premise is untrue, the rest is meaningless.
>
>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.

>No matter what words you use for what you do in between, you are mapping
>classes to tables, aren't you?

No, I'm not. Like I said before, if you were to educate yourself even a little, you wouldn't sound quite so ridiculous.

>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.

>> >Lets take Java as a starting point.
>>
>> Let's not.
>
>Which programming language do you prefer?

None.

>> You want to store some of what? The representations? If an object
 instance
>> has multiple possible representations, which one do you want to store?
>
>You store objects.

Again, object classes, object instances, object variables, or object values? You are not very precise in your descriptions.

>Multiple representations?
>They are represented by multiple access methods to objects within the
>programming language. They do not need to be persisted.

Huh? At least one representation needs to go into the database or you haven't stored anything!

>> Well, as a programmer, I would certainly want to know what happens to my
>> inheritance hierarchies. I certainly would not want them to change
 without
>> my knowing!
>
>???
>What you store is what you get back.

I'm not concerned about what I store. I am more concerned about the guy writing the other application that also changes my data.

>> I certainly would not want my array to turn into a hashtable just because
>> some other application prefers to deal with the same data that way!
>
>I would not want to care about what happens with my objects for
 persistence.
>If I have the chance here to save work and gain performance, what is the
>drawback?

The opportunity does not exist so the point is moot.

>> >The more work the database engine does
>> >for me here, the more productive I can be.
>>
>> Huh? Inheritance hierarchies, arrays and hash tables are physical
>> limitations imposed by the programming language. The more physical
>> limitations the DBMS imposes on the data, the less productive you can be!
>
>So your starting point is a relational database as a fixed paradigm?

There goes the bullshit antennae again.

My starting point is sound, fundamental data management principles. I think it's a good starting point, don't you?

>Sadly this currently seems to be the case for many development teams.

Rhetorical bullshit.

>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!

>Doing this <Mapping object classes to tables...>

...is dumb to begin with.

>- performance is lost
>- maintenance work is an awful job
>- unnecessary complexity results in spaghetti programs

It's not hard to conclude dire consequences when one starts with a stupid premise. It's as easy as proving one's axioms.

>Tuning the system to make up for performance problems
>- business logic is misplaced to triggers and stored procedures

That is not a relational solution.

>- natural correct object hierarchies are replaced by design trade-offs

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

Regards,
Bob Received on Sun Jul 22 2001 - 01:28:58 CEST