Re: OO and relation "impedance mismatch"

From: Marshall Spight <mspight_at_dnai.com>
Date: Sun, 03 Oct 2004 21:48:28 GMT
Message-ID: <Ms_7d.301694$mD.88577_at_attbi_s02>


"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cjpb7e$3ob$1_at_news.netins.net...

>

> OO languages support Relations as a type -- you can either use a library
> with Relation already defined as a type or write your own Relation class.

This is true, but not altogether helpful. Imagine Java without the collections classes-- you could just write your own! And implementing a full relational dbms would be even harder.

But perhaps the point you are making implicitly is one I'll make explicitly: OO languages have been far and away the most successful at providing programmers with user-defined types of any approach thus far. (And I'd put SQL and existing SQL database as down near the bottom of the list.) Yes, much of OO is still ad-hoc and not well grounded, but doesn't mean it hasn't been spectacularly successful. And it also doesn't mean it isn't on its way to being well-grounded.

> Yes, and that is only one of the reasons that my finger points to the RDBMS
> as the source of the mismatch. The OO-RDBMS mismatch is similar to the
> XML-RDBMS mismatch, which is similar to the pre-RDBMS to RDBMS, which is
> similar to the English-RDBMS mismatch in that all of the types that have a
> mismatch with the RDBMS permit non-1NF structures. Relational theory now
> sortof, kindof incorporates nested relations, but that is primarily in
> theory and not where populated relational databases are today.

I know you love to hammer on the 1NF point, but that's not the core issue. The core issues is that we have on the one hand a language devoted to working with sets as collections to the neglect of user-defined types, and on the other hand we have languages that do a great job of allowing users to define types while completely neglecting collections, (on the theory that they can just be done as classes, which doesn't work all that well.)

> The other mismatch has to do with the constraints, where both the language
> and the database want to be the primary source for the definition of such.
> The constraints must be available to both and if they are coded in a
> proprietary language of the database, that makes it very difficult to
> migrate from one database to another and makes it difficult for the language
> to have access to the constraints at the points they need that information.
> If they are coded in an application, then the database is not "managing" the
> data.

We agree on this point: constraints have to be available to applications; centralized management is not *sufficient* to a well working system. (Although I feel it is *necessary* which I don't believe you agree with.)

> Constraint information is needed throughout applications and not just at the
> point of commiting data. In fact, that's way too late to apply the
> constraints. If you can lock out all transactions & queries with the
> database that do not go through designated APIs (such as web services)
> rather than locking them using the proprietary DBMS, then you don't need to
> have the database apply these constraints since they will be applied up
> front of that necessarily.

Going through an application-defined API is a brittle approach that will fail sooner or later. Web services are a cheap hack in response to the massive marketplace success of html and http; they aren't a solid platform to build data management on.

But the "proprietary" aspect you bring up is a good one: as long as applications and the dbms communicate as poorly as they do now, we have a problem.

Marshall Received on Sun Oct 03 2004 - 23:48:28 CEST

Original text of this message