Re: Object-relational impedence

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

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.

> 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. 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. As for the bag RDBMS, among the thing it contains are object-relational impedance, SQL, poor performance, unpredictable behavior, maintenance costs, etc.

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de