Re: Object-relational impedence

On Thu, 6 Mar 2008 15:20:48 +0000, Eric wrote:

> On 2008-03-05, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:

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

I didn't. I just asked for a specification of "any logically possible criterion" to give you enough rope to hang yourself.

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

Discovering new things is called research. If I were at a university I would enjoy surprises, but then RDBMS would draw my attention even lesser than now.

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

You already said that. But you didn't confirmed understanding the implications I wrote about.  

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

In your other post you said that data is a belief. So information must be another one, even more fuzzy and thus requiring a greater portion of mysticism...

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

How one follows from another?

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

Let I store all these data in a RDBMS, would in be same data but different sine? Does SELECT y FROM sine WHEN x= behave differently from sine?

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