From: Dmitry A. Kazakov on
On 29 Jan 2007 14:32:20 -0800, frebe73(a)gmail.com wrote:

>>> Are you totally ignorant about spatial databases?

>> No, I am of any "relational data structure" (RDS) for the problem
>> described. Your references to some software products are irrelevant as long
>> you cannot assert that they solve the problem using such an RDS. In case
>> they do, please, don't hesitate to present it us.
>
> How do you expect such assertion to be made? Disassembling the
> executables? I understand that you don't trust any documentation, but
> why do think products like Oracle Spatial and PostGIS have specalized
> index types, if they are not able to make use of them?

Whether I trust Oracle et al is of no interest. To assert is that their
implementations could use RDS in a sufficient way. If they could, then, it
should be no problem for an experienced relational guy like you, to present
us a sketch of such RDS. Clearly, that should be possible to do in SQL.

So far, we saw that

CREATE TABLE Space (double, double, double)

was not enough. There must be a magical index structure here. Describe that
index in SQL. That's all.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on
On 29 Jan 2007 18:35:06 -0800, Daniel Parker wrote:

> On Jan 29, 6:27 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>> On 28 Jan 2007 16:04:30 -0800, Daniel Parker wrote:
>>
>>> A relation is a value, a relation is a
>>> set of tuples, every value is a value of some type, the type of a
>>> relation is parametrized on the type of its member tuples. And???
>
>> Then the tuple (T, r) is a relation object. Here T is the type of the
>> relation r and r is the value of, i.e. the relation itself.
>
> A relation object. Is that what you meant when you said " An object
> is a relation, and it is very convenient to use"? I suppose (double
> type, double value) is a double object. Does this mean I can say "An
> object is a double and it is very convenient to use"?

It was two different questions. I was answering to how to get at objects
from values. As for the first question, any object can be trivially
considered as a relation to its type or value: (T, r) of T, or countless
other relations it has to other objects. Which of these relations are
exposed in the programming language and which not is a big question. I can
well imagine a sort of relational UML. I doubt it would be very productive,
but UML isn't either... (:-))

>>>> RA is about specialized containers and thus deserves no any special
>>>> treatment.
>>
>>> RA is about a formal logical system about relations,OK, if you take a mathematical definition of algebra.
>
>> But in the context of this thread, RA refers to its application for software developing and
>> design.
>
> RA doesn't mean that in any context.

Read it "RA."

>>> and a small
>>> number of operations that map relations into relations. What is the
>>> special treatment?It is an attempt to encapsulate it into a physically separate component
>> interfaced though its own language. That thing is called RDBMS, which is
>> responsible for implementation of RA.
>
> RDBMS demonstrates the benefits of basing software on a formal logical
> system. OODBMS demonstrates the problems of not doing so.

Yes. There are sufficient problems in foundations of OO. Here I mean
OO=types systems, stripped of religious/OOA/D aspects.

> Venture
> capitalists appreciate the difference, even if their command of set
> theory is a little rusty.

I would be very happy if they really did, but unfortunately they just don't
care. But this is a discussion for another day.

>> Because this design is obviously flawed, proponents of RDBMS try to argue
>> that RA is capable to describe everything in the best possible way.
>>
> On the contrary, it is you that is claiming that OO is capable of
> describing everything in the best possible way. Really.

No. What I claim is that we need typed systems to handle complexity. This
does not imply that we could solve any problem. Another my claim is that RA
is a typed system of special kind. One can extend it into a richer system
(as Date tries to do), or else put it into such a richer system. In any
case it the typed systems which are interesting for us programmers, RA is
not.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: frebe73 on
> >>> Are you totally ignorant about spatial databases?
> >> No, I am of any "relational data structure" (RDS) for the problem
> >> described. Your references to some software products are irrelevant as long
> >> you cannot assert that they solve the problem using such an RDS. In case
> >> they do, please, don't hesitate to present it us.
>
> > How do you expect such assertion to be made? Disassembling the
> > executables? I understand that you don't trust any documentation, but
> > why do think products like Oracle Spatial and PostGIS have specalized
> > index types, if they are not able to make use of them?Whether I trust Oracle et al is of no interest. To assert is that their
> implementations could use RDS in a sufficient way. If they could, then, it
> should be no problem for an experienced relational guy like you, to present
> us a sketch of such RDS. Clearly, that should be possible to do in SQL.
>
> So far, we saw that
>
> CREATE TABLE Space (double, double, double)
>
> was not enough. There must be a magical index structure here. Describe that
> index in SQL. That's all.

How do you describe B-trees in SQL? Does it mean that B-trees doesn't
make it possible for SQL queries to perform faster than linear time.

What is magical about kd-tree or r-tree index? There are all possible
kind of index implementations availible for SQL databases.

Fredrik Bertilsson
http://mybase.sf.net

From: ggroups on


On Jan 30, 6:03 am, "topmind" <topm...(a)technologist.com> wrote:

t> Robert Martin wrote:

>>On 2007-01-28 11:41:50 -0600, frebe73(a)gmail.com said:

>>>The most common data structures used in current programming languages
>>>are lists and maps

>>Not so fast there partner. The most common data structure used in
>>current programming language is: object. An object is a tuple, very
>>similar to a table row. Objects can be connected into graphs through
>>the use of pointers.

> Objects are essentially maps with a little syntactic surgar. In the
> simplest OO languages, objects and maps are nearly indistinguishable.

Is that so ??

Please feel free to provide us with the names of the "simplest OO
languages" for which the above is true.

If you cannot do the above, please feel free to show us how an OOPL
(with inheritance etc) would be implemented as "maps with a little
syntactic sugar" .


Regards,
Steven Perryman

From: frebe73 on
> >>>The most common data structures used in current programming languages
> >>>are lists and maps
> >>Not so fast there partner. The most common data structure used in
> >>current programming language is: object. An object is a tuple, very
> >>similar to a table row. Objects can be connected into graphs through
> >>the use of pointers.
> > Objects are essentially maps with a little syntactic surgar. In the
> > simplest OO languages, objects and maps are nearly indistinguishable.Is that so ??
>
> Please feel free to provide us with the names of the "simplest OO
> languages" for which the above is true.

JavaScript, PHP.

Fredrik Bertilsson
http://mybase.sf.net