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

>> Network model databases, however, represent data with pointers and other
>> physical constructs that vary greatly among different vendors. Further
>> issues such as shallow copies vs. deep copies, pointer swizzling,
 implicit
>> back-pointers etc. vary as well. Every different implementation of
 network
>> model database changes the meaning of the data implied by physical
>> constructs by introducing often subtle differences in interpretation.
>
>This is it?

This is a small subset of the ways network model DBMSs expose physical implementation details in their logical model.

>Your list of points is quite irrelevant in practice.

Actuall, my list is extremely relevant in practice. Especially, in the context of the discussion of portability.

>Object databases differ by tons of further details which are by fay more
>important than the ones you listed.

Well, I admit that the object databases cannot even agree on what their data model really is, and that the truly logical differences are even more confounding.

>Doug Barry maintains a factbook on object databases, to bring some light
>into drastically differing products.
>http://www.odbmsfacts.com/

I've read some of Barry's work. It seemed to me that the quality of his worked dropped off the longer he was involved with ODMG. I haven't read recent work of his, though.

>Object databases do have one issue in common:
>They try to hide implementation issues from the user.

Well, I know that a lot of programmers actually believe that fallacy, but it truly is false. The relational model by requiring physical independence actually does hide implementation details. Even SQL databases do a better job of this than any OODBMS ever conceived.

>Pointers and OIDs are preferrably *not* visible.

Actually, you cannot hide them completely. I thought that Lee already covered this one with you. Just because the use cannot display a textual representation of the OID does not make it invisible. The navigational requirement implies that the OID is visible no matter how much you try to disguise that fact.

>[changes of implementations over years]
>> >The work to reflect changes is to be done in the programming code, am I
>> >right?
>>
>> Nope. Many applications need not change at all because their specific
 needs
>> might not change from one year to the next. Logical independence,
 delivered
>> by views, provides all that's necessary. Of course, that subset of all
 the
>> applications that do need to change from one year to the next will have
 to
>> change in the code. Presumably, they might use new views on the database
 as
>> well.
>
>I don't understand where you are headed here.

I'm not headed anywhere -- I'm already there. Relational, by requiring logical independence, handles schema evolution beautifully. Your prior claim that the OODBMS requires no administration or maintenance is fatuous, at best.

>In a previous posting you implied that some handling might be changed.

I implied it and addressed it in the later posting too. Were you not paying attention?

>Certainly business logic can not be changed by rewriting views.

Ahh, but all of the business logic that need not be changed can.

>> >There are object databases that automatically handle schema changes.
 Still
>> >there is no maintenance work necessary to adjust the database schema. It
>> >will continously be analysed by the database engine.
>>
>> Right. And if pigs had wings they would fly. I suppose I just imagine the
>> schema change I want, the database reads my mind and takes care of all
 the
>> rest?
>
>No.
>You change you classes *only*.

With relational, I don't even have to do that. Relatonal is so much easier and so much simpler. The whole goal is to not have to change any code.

>There is no need for a change to tables, mappers, queries, backups and
>whatever.

If they change, then they change. Requiring me to change my code to change these other things is backwards and regressive.

>> >If you think you need proxy objects to provide a different view at
 employee
>> >objects from HR and from Payroll, why not create the classes for them?
>>
>> What exactly is a different view at an employee object? Is it a different
>> view at the data? Is it different behaviour? Why would I want to create
>> different classes for them at all? It's much simpler to create relational
>> views in the database and handle application issues in the applications.
>
>Whats your definition of "simpler"?

The one in the dictionary.

>You can create object views in the same way as you can create database
>views. It is one intermediate layer that translates data.

So, it is a view on the data, and not a view on the behaviour? I thought an object was both. Are you saying that an OODBMS just stores data? In that case, what is the difference between it and a network model database?

>> >If you want versioning, fine.
>>
>> Versioning is an inferior attempt at addressing physical/logical
>> independence. When I want versioning, I use PVCS or SourceSafe --
>> where it's appropriate. In the database, I will use relational views.
>
>Are we talking about versioning of sourcecode or versioning of persisted
>objects?

I'm talking about versioning. Relational already handles the issue better and without adding yet another unecessary concept.

>As above:
>Similar to relational views an object database can use classes/objects to
>translate data.

Actually, this is not entirely true. A view does more than translate data, it is a relation. The principle of closure is extremely important here as is the declarative nature of views.

>> >Why not work with different versioned classes derived from a base
 employee
>> >class for the next year?
>>
>> How do I ensure that all of my users exercise the correct code? If they
 run
>> last year's version, my company might not be in full compliance with
 federal
>> statutes.
>
>By not allowing old versions to log in.

In other words, I have to change all of my applications to use the latest versions or the applications no longer work. In a relational system, I can still run my older applications and I cannot avoid the current constraints -- all without changing a single line of my application code or even recompiling.

>> >IT does change, and it changes quickly.
>>
>> Ahhh, but sound fundamental principles change very slowly. It is
 precisely
>> my knowledge of sound fundamental principles that has allowed me to
>> adapt to the rapid changes in my industry.
>
>You are about to miss a new tornado.

Thank God! In case you haven't noticed, it's best to avoid them.

>> >Object-oriented languages were not common 10 years ago.
>> >Today they are.
>>
>> Well, I have been writing object based and object oriented programmes
 since
>> 1987. Let's see.... that's 14 years. I guess that makes me an early
>adopter.
>
>How many object databases did you test so far?

Enough. I used to maintain the code for a proprietary network model database as part of one of my early jobs.

>You might have been an early adopter 24 years ago.
>Early adopters also grow old and tired of changes.

Not me. I've learned two new programming languages since the new year, and successfully put them to work in commercial environments.

>> >It is time for object databases.
>>
>> Bullshit.
>
>I wish you would always use this argument.
>It would save me a lot of work answering.

It's not an argument. It's an observation.

>Why don't you supply the design that you would use?

No such single design exists. There are innumerable designs I might choose depending on the full set of requirements.

>> >What is your favourite flavour?
>>
>> They both suck. What's your point?
>
>I was trying to point out that the choice of data model has an impact on
>performance.

Well, it doesn't so you might as well give up now.

>> I disagree with all of your conclusions regarding what I will get. I
 don't
>> consider outer joins relational; I think that NULLs are Codd's big
>mistake.
>
>Possibly.
>Today we have to live with NULLs.

Actually, we don't. Those among us who know better avoid them like the plague.

>Outer joins are essential.

No, they are not. Your statement is simply untrue.

>> The object-relational mismatch exists because relational languages are so
>> much higher-level than current object languages.
>
>???

!!!

>> Wrong. OIDs are exposed to users whether they see the actual
 representation
>> or not.
>
>???

!!!

>> When the OODBMS forces one to access a contained collection through
>> the containing object class, it exposes the linkage to the user.
>
>The linkage is accessed in the programming language with the notation
>object.member

Well, if your only supported logical access method requires the programming language, your DBMS exposes the linkage. I wouldn't hold the requirement of the programming language up as an advantage, though. The thought seems a little silly, don't you think?

>This is natural in OO languages and typically does not cause programmers
>headaches.

When two different programmers writing differnt applications that have to share the data in the DBMS disagree on how to link the data and how to best navigate the database, believe me: it causes plenty of headaches. Been there, done that!

>OIDs are not exposed.

Untrue. Given the number of times I've seen this demonstrated to you, I have to conclude that the untruth is intentional. That doesn't reflect very well on your character, you know.

>[Object database handling of OID]
>> So every vendor transparently handles every other vendor's OID
>> transparently? Get real!
>
>In fact this happens, if OIDs never appear in application code, which they
>don't have to.

We weren't discussing application code. We were discussing portability among DBMS vendors.

>You might like to experiment with some object databases to understand how
>this works.

Don't worry. I understand this all too well.

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