Re: OO and relation "impedance mismatch"

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0410030250.770e7582_at_posting.google.com...
> Troels Arvin <troels_at_arvin.dk> wrote in message
news:<pan.2004.10.02.13.18.03.39531_at_arvin.dk>...
> > On Sat, 02 Oct 2004 04:00:13 -0700, Fredrik Bertilsson wrote:
>
> > I believe that it's true that there still are annoying obstacles which
> > have to be taken care of when using an RDBMS as a storage backend for
> > OO-coded programs.
>
> To use an RDBMS as a storage backend is to misuse an RDBMS. DBMSs are
> for data management, not for dumb storage.
>
> > Part of it probably has to do with the fact that relational databases
are
> > set-oriented whereas OO languages are not.
>
> OO languages don't support the fundamental relational structure: the
> relation. It is very evident that a language that does not support
> relations is not very well suited to work with relational databases.

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. I'm missing the point on this one. It seems to me that OO languages are better at working with Relation types than are procedural languages.

> > But that - by itself -
> > need not be a problem: Using the right tool for the right situation
should
> > always be better than trying to solve everything by one principle.
>
> That is necessarily a problem, but a problem we can workaround.
>
> > Then there is type support: Some of the data types found in - e.g. - SQL
> > don't have out-of-the box, perfectly matching types in the major OO
> > languages.
>
> They have in the most modern languages like VB.NET and C#.
>
> > The above problems are not unique to the RDBMS<->OO situation. They are
> > actually general to RDBMSes and any imperative language (that I know
of).

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.

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.

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.

cheers! --dawn Received on Sun Oct 03 2004 - 19:00:21 CEST