Re: Object-relational impedence
Date: Wed, 5 Mar 2008 22:08:04 +0100
Message-ID: <1gnqeu00kqi7y.d25moahv9acq$.dlg_at_40tude.net>
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."
>> 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.
>>> 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.
>>> 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.
> 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.
>> 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.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Wed Mar 05 2008 - 22:08:04 CET