Re: Object-relational impedence
Date: Tue, 4 Mar 2008 20:26:01 +0000
Message-ID: <slrnfsrc2p.nmr.eric_at_tasso.deptj.demon.co.uk>
On 2008-03-04, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:
> On Tue, 4 Mar 2008 17:58:02 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:
>>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>>
>>>> On 2008-03-04, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> 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 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.
> poor performance,
> 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