Re: Object-relational impedence

From: Eric <>
Date: Tue, 4 Mar 2008 20:26:01 +0000
Message-ID: <>

On 2008-03-04, Dmitry A. Kazakov <> wrote:
> On Tue, 4 Mar 2008 17:58:02 +0000, Eric wrote:
>> On 2008-03-04, Dmitry A. Kazakov <> wrote:
>>> 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).
>> So you will always know, in advance, what all the possible future
>> applications will want! I hope you are not crazy enough to believe that.
> No, I am. When I am looking for a solution I have to know what is the
> problem. Is that crazy? Further, dealing with a generalized problem I shall
> consider what would be the consequences of such generalization. There is
> always a price to pay. You certainly have heard about computability, NP
> problems and such stuff. But just going from 1ms to 100žs makes a huge
> difference.

Everything has a price. You have to choose. What I see is someone taking only the short-term view.

>> So you are left with minimising "things it cannot do". I guess that
>> means you should have something which can make the data available to any
>> application that asks, according to any logically possible criterion.
>> Did you know that this is what an RDBMS does?
> No it does not, when "asking" is defined as diffuse as in the natural
> language. There exist certain limitations on what and how can be asked.

That's what I said - logically possible criteria.

> These limitations should be specified as functional and non-functional
> requirements.

If possible. What I meant was that you should minimise the limitations on both the expected and the unknown futures.

> If you prefer to buy a cat in the bag named RDBMS (or
> whatever), that's up to you. I merely state that there is always something
> in any bag.

Cat? What cat? But actually, see what I said above about price.

> As for the bag RDBMS, among the thing it contains are
> object-relational impedance,

You made this one up because you don't understand.

> SQL,
OK, it's not the perfect language, but what is? And it is possible to have an RDBMS that doesn't use it.

> poor performance,

Relative to what? Where are the tests? Do you install an RDBMS product and just go with whatever myths you have heard lately, or do you get a product specialist to sort it out?

> unpredictable behavior,

Please explain. Unless you're talking about bugs, but everything has those.

> maintenance costs,

Everything has those too. Again, I have to assume that you take only the short-term view.

> etc.

What else would you like to make up?

>> Perhaps not, since you have also said that "data are irrelevant".
> Yes, I did. I am working mainly in the area of industrial data acquisition
> and control. It might sound funny, but being so close to "data" one starts
> to better understand why data are irrelevant.

Aha! Your data is transient, and what you are mostly doing is transforming it. I at least have no problem with using OO programming for that. Also, that explains your short-term view. But what do you do with the data (presumably transformed) that does get kept for longer? Put it somewhere that will be available for a variety of expected and unexpected uses? But we were here before!

E Received on Tue Mar 04 2008 - 21:26:01 CET

Original text of this message