Re: Object-relational impedence

On 2008-03-05, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:
> On Wed, 5 Mar 2008 12:12:47 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:
>>> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>>>
>>>> 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.
>
> This does not equate to "logically possible criteria." It is "something
> that can understand this."

My statement had two parts, they are about different things both interacting with the same data. Why are you trying to claim that I said the two parts are the same, just so you can say they are different?

>
>>> 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.
>
> This is not a prejudice, this is the point. I don't want to be surprised.
> Engineering is about predictability.

The surprise is you discovering something you did not know, it is not part of the engineering of the problem or the solution.

>
>>>> 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.
>
> From this I conclude incompleteness of the approach. There is nothing bad
> in that. At this point you should have said, "OK, how could we reason about
> the applicability of this approach (and other approaches)." A framework
> where that could be done is that common ground where c.d.t. and c.o. would
> unite.
>

No-one but you ever said that the approach was complete, and you seem to have said that only to argue against 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!
>>>
>>> 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.
>
> Theorem: for any collection of data, there exist somebody who does not need
> it.
>

That's what I said. I only said it to point out its irrelevance.

>> 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.
>
> No. Any logical is physical on another abstraction level. Ants do not
> listen to music. Information does not exist without a receiver.
>

False, unknown, false. I might admit that information is not useful without the possibility of a receiver, but I don't see that it gets us anywhere. And I thought we were talking about data, not information.

>>> 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.
>
> No you get me wrong. Of course we do logging, in fact a lot of. The system
> behaves as if it "kept" things. Whether it physically keeps them is an
> implementation detail. Consider sine. Does it keep its output? It is a
> meaningless question. You can tabulate sine and keep the table, you can use
> Chebyshev's polynomials, or you can ask an oracle. It is no matter. Sine is
> a behavior of real numbers.
>

And you never analyse those logs? Anyway, you could, so they are data.

Sine is not a reasonable example, nor is it a behaviour. It is a mathematical function, a mapping. How can a mapping keep anything? But a computer program can keep the number that it passes in to an implementation of sine, and the number that it gets back. They are data.

E Received on Thu Mar 06 2008 - 16:20:48 CET