Re: Object-relational impedence

On 2008-03-04, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:
> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>

 <snip>

>>
>> That's what I said - logically possible criteria.
>
> What about things which cannot be spelt in SQL?

Use the query language (not necessarily SQL) to pass the data to something that can deal with it.

> What about response times?
> Can you specify/guess an upper bound for all requests? For a certain subset
> of?

This is just a prejudice - get the right RDBMS and the right expert to tune it (specifically for what it must do, not generically) and you might be surprised.

>
>>> 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.
>
> No optimum exists under these conditions.
>
>>> 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.
>
> You said that the price has to be paid. Right, but the question is about
> performance/price ratio. You can buy a bigger car, but it would require
> more gasoline and it would be more difficult to park. Software developing
> is an expensive thing.
>
>>> As for the bag RDBMS, among the thing it contains are
>>> object-relational impedance,
>>
>> You made this one up because you don't understand.
>
> What didn't I? That impedance exists or that it does not?
>
>>> 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?
>
> Come on, show me the nearest neighbour search in ten-dimensional space
> implemented in RDBMS. What would be the complexity of? You should clearly
> understand that it is possible to break the neck of *any* indexing method.
> This refutes the argument to "any logically possible criterion.".
>

But I don't believe that an RDBMS can do everything. I would not be surprised to find the data defining the ten-dimensional space in an RDBMS, but I would never expect to do such a calculation in the query language.

>>> unpredictable behavior,
>>
>> Please explain. Unless you're talking about bugs, but everything has
>> those.
>
> And what are the means available in order to prevent bugs? How much RDBMS
> support static analysis? SQL is practically untyped. Design by contract,
> how? Code reuse is close to none, well, code is evil, why should we reuse
> it? Upper bounds for memory footprint? For response times?
>
>>> maintenance costs,
>>
>> Everything has those too. Again, I have to assume that you take only the
>> short-term view.
>
> No,I mean long-term maintenance costs.
>
>>> etc.
>>
>> What else would you like to make up?
>
> Actually I don't want to concentrate on critique of RDBMS. It is a hardware
> to me. I would buy one in case I needed it.
>
> My objective is rather data-centric view. Which is IMO the reason for
> object-relational impedance. BTW, I see nothing wrong in RA, which has in
> my view fully independent on the notion of data. RA would nicely fit into
> OO as a set of types with corresponding operations.
>
>>>> 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.
>
> Well, one viewed it this way in 50-60s, I guess. But it is a long time
> since one dropped this data-centric view on the system as a huge signal
> filter. This model does not scale and is inadequate (event controlled and
> non-numeric things, GUI etc).
>
>> 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!
>
> Yes, here we go again. Data are meaningless if usage is unexpected. Nobody
> can use a CD-ROM in a wind-up phonograph, deaf people notably.

No collection of data is useful to everybody, so deaf people have got nothing to do with it.

Other than that, you have just demonstrated a lack of understanding of the difference between the logical and the physical. It is possible for me to collect the necessary bits of technology to transfer a piece of music from a CD-ROM to a disc or cylinder for the wind-up phonograph. It is still the same piece of music.
>
> The system does not keep anything it exists and behaves.

But it has inputs and outputs. There may also be a need for it to record some of its behaviour. There may be a reason to keep some of the outputs, or even the inputs (for later extended analysis?). If you have a system that genuinely keeps nothing, I have no argument with how you choose to create it, as long as it works.

> Deployment of DB
> there is always problematic. There are much ongoing efforts in this area in
> recent years, mainly to standardize the schemas. That is not enough,
> because relational model does not fit. Channels are largely event
> controlled with time stamps. So you cannot make any reasonable relations
> beyond (time, value) without data corruption. The queries would be like
> "give me the oil temperature profile when the velocity was out of range for
> longer than 10s before the event E." You need various interpolation
> methods, calculated channels and ones simulated from previously recorded
> measurements. Channels are created and destroyed, their properties change.
> The end effect is that when DBs are used then only marginally. I remember
> an amusing customer requirement: "we want to be able to run our tests even
> if the DB server is off-line." (:-))
>

E Received on Wed Mar 05 2008 - 13:12:47 CET