Re: OO and relation "impedance mismatch"

On Sat, 02 Oct 2004 04:00:13 -0700, Fredrik Bertilsson wrote:

> OO people often claims that there are an impedance mismatch between
> the OO model and the relational model, that makes it very hard use a
> relational database when you are using an OO programming language.

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.

Part of it probably has to do with the fact that relational databases are set-oriented whereas OO languages are not. 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.

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.

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

However, I believe that the impedance mismatch is given more attention in the OO World because that World is _remarkably_ keen on OO "paradigms". 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.

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. Transactions are dealt with in several layers, etc. The blame for this should not be put on the middleware-fans exclusively: RDBMSes tend to lack _usable_ error reporting; therefore, the middleware layers cannot solely rely on the RDBMS to do all the constraint handling if sensible error handling is to be performed (including sensible error reporting).

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

1. RDBMSes got better at useful error reporting, which the application layer could easily translate into meaningful error messages for the end user. That way, a lot of redundant, defensive error avoidance code could be torn out of the middle ware/application.
2. Relations in RDBMSes were easier to query for metainformation: E.g., if it were easier to deduce valid values for a column, the application could automatically map columns to useful end-user widgets. JDBC and similar RDBMS access software already offers some metadata information about tables (which I think should be used more), but as far as I know, there is no easy way to translate a set of CHECK constraints into auto-generated data types in the application layer. For once, I actually want to praise MySQL: MySQL has the ENUM type which is easy to translate into a data type with a discrete set of valid values. Unfortunately, MySQL's ENUM type is not gotcha-free: http://sql-info.de/mysql/gotchas.html#1_3
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.
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 result of 1 and 2 could be less middleware "obesity" problems and more centralized constraint handling. Points 3 and 4 are actually wishes for less tendentious religiosity in the OO World: OO is a (sometimes) practical way to organize code, not an ever good, all-encompassing computing ideology.

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

-- 
Greetings from Troels Arvin, Copenhagen, Denmark