Re: Object-relational impedence

From: Dmitry A. Kazakov <>
Date: Tue, 4 Mar 2008 21:44:56 +0100
Message-ID: <1lclz34telbup$>

On Tue, 04 Mar 2008 19:45:30 GMT, David Cressey wrote:

> "Dmitry A. Kazakov" <> wrote in message
> news:4bza4t1lmhj9.1734ger7g3zac$

>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>> On 2008-03-04, Dmitry A. Kazakov <> wrote:
>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>> any possible application. So if you use OO you are saying "there will
>>>>> never be any other application that will need my data".
>>>> No, it is engineering which says so. It translates as "put the requirements
>>>> first," or simpler "pigs do not fly."
>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>> application and combine it with our data so that we can..."!
>> You should plan this use case in advance. That would be a requirement. A
>> system can only do things it was designed for. (This applies to RDBMS as
>> well). For each application exist things it cannot do. That implies: either
>> A) there will never be any other application that will ask to do these, or
>> B) the application is incorrect (= does not fulfill the requirements).

> This is true for an RDBMS. But more to the point, can a relational (or
> SQL) database be designed in such a way that it has moderately good support
> for thousands of anticipated queries, of which only a few dozen will
> actually come to be used ? And will those few dozens of uses provide the
> appropriate payback on the investment in building the database?

> Based on my experience with databases, I offer the firm opinion that the
> answer is yes.

That's OK to me. But the question, as I understood it, was about qualitative design changes. My point was that there is always a presumption of the nature of changes which can and of those that cannot happen. A design is good when this presumption matches the reality. From this point of view there is no difference between deployment of OO or RDB solutions. As engineering both would solve some class of problems and anticipate quantitative changes of certain kind, but not qualitative ones.

When I read what Eric wrote, that made me think that he believed that RDB would solve all problems and thus anticipate any changes. This would be obviously wrong. I guess that his hidden argument was "because RDB apparently solves all problems, then data-centric view is the right one." Yet another logical fallacy was a data-centric problem statement: "there will never be any other application that will need my data," used in order to prove data-centric view itself. In OO problems are not modeled in terms of applications using data. This alone does not yet imply anything about the problems being solved. Actually we all are solving similar problems, otherwise there would be no such quarrel between us.

P.S. OO is especially focused on maintenance. H.S. Lahman already wrote about it in another post, so I need not to repeat it here.

Dmitry A. Kazakov
Received on Tue Mar 04 2008 - 21:44:56 CET

Original text of this message