Re: OO and relation "impedance mismatch"

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.

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

Tutorial D is also imperative.

> However, I believe that the impedance mismatch is given more attention in
> the OO World because that World is _remarkably_ keen on OO "paradigms".

And because "relational" guys seldom have to code in OO languages.

> Those paradigms tend to be not very well founded or defined, and there
> seems to be a tendency for creations of "paradigm of the year", especially
> in the Java World (e.g.: some years back, inheritance was cool; nowadays
> it's seen as very un-cool.). Sometimes, "beans" are hot; at other times,
> it's "agile modeling". No matter what's currently hot, proponents of the
> hot trend tend to disregard any technique which could decrease the
> "purity" of their pet paradigm.

Agreed.

> N-tier architectures constituate a problem of their own, I think: With the
> great focus on middleware, a lot of redundant coding seems to be done:
> Constraints are handled in the RDBMS, in the n layers of middleware and
> perhaps also in the client application.

And the worst part is that the redundant constraints are handled procedurally in the middleware and the client.

These middlewares are often specific purpose network DBMSs. A return to the stone age.

> Transactions are dealt with in
> several layers, etc.

Indeed, many coders implement their home made transactional systems without reading any text on the topic, and then they hide a DBMS with a good and well tested transactional system under their crappy middlewares.

> I think that the impedance mismatch would be less of a problem, if

> 3. The OO World would focus less on paradigm/pattern/framework
> of the year/month/week and focus less on hiding the fact
> that many data are eventually stored in an RDBMS.
> In other words, cut down on the fear for coupling.

And they should focus less on vendors marketing junk and focus more in learning the theoretical foundations of the profession.

> 4. The OO World would accept RDBMS-software as valid, powerful
> technology which sould be exploited and given responsibilities,
> in stead of only being viewed as a necessary evil. One of
> the consequences of this is to spend less time reading the
> latest UML book; read up on relational theory, SQL, etc.,
> in stead.

The problem is that most books on SQL databases are junk, specially the product oriented books.

> While facing the risk of being seen as a make-love-not-war tech hippie, I
> suggest that the term "impedance mismatch" should be terminated and
> replaced with something less pessimistic, such as "practical
> issues in combination of forces".

I disagree, the problem exists, but it is nothing compared to the lack of knowledge on the fundamentals by most coders and DBAs.

Regards. Received on Sun Oct 03 2004 - 12:50:03 CEST