Re: OO and relation "impedance mismatch"
Date: Sat, 02 Oct 2004 15:18:06 +0200
Message-ID: <pan.2004.10.02.13.18.03.39531_at_arvin.dk>
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.
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.
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
- 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.
- 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
- 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.
- 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.
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, DenmarkReceived on Sat Oct 02 2004 - 15:18:06 CEST