Database Theory Links

[Brian T. Rice]

At 02:47 PM 4/2/00 -0400, Kyle Lahnakoski wrote:
>Tom Novelli wrote:
>> Kyle Lahnakoski <kyle@arcavia.com> wrote:
>> > Massimo Dentico wrote:
>> > > -
ftp://ftp.netcom.com/pub/hb/hbaker/letters/CACM-RelationalDatabases.html
>> > >
>> > > In my experience he is right. However, even OODBMS are not the ultimate
>> > > solution, at least in the current state.
>> >
>> > I will agree that no all data can be effectively represented in a
>> > database.  I found the theory excellent starting point for defining,
>> > what I call, "set operations".  There are currently * basic DB operators
>> > (depending on who you talk to) select, filter, join, aggregation, union,
>> > intersection, difference, and cartesian product.  I am trying to write a
>> > document on a ninth DB operator: the "Self Join"; it will complete much
>> > of DB theory's shortcomings (but still not a holy grail).
>> 
>> Self Join... do you mean a simple way to nest subassemblies to an
>> arbitrary level, rather than an explicit join for each level?  That would
>> certainly help.
>
>Yes, and making it theory will help implementors make the self-join
>efficient.  Right now many vendors provide it, but it sucks.

[Banter about database ideas deleted for brevity.]

>----------------------------------------------------------------------
>Kyle Lahnakoski                                  Arcavia Software Ltd.
>(416) 892-7784                                 http://www.arcavia.com

Well, I usually completely ignore threads like these, because they usually
find out the "Tunes way" to answering their questions at some point.
However, I see that the discussion is only diverging further from the
entire point of having discussion about Tunes.

You've argued that we on Tunes ignore the aspect of meta-data, and that
database theory is somehow more 'informed' on these issues. I'm saying that
This Simply Isn't So, and that this thread is redundant to the Tunes
subject matter if it discusses database theory as anything approaching an
answer.

The way you employ meta-data according to Tunes is to handle objects that
annotate the objects they describe. Such objects can be collected and
managed by the usual object-oriented store techniques or some improved
implementation with orthogonal persistence. All this business about joins
and other SQL stuff can be perfectly well-handled in existing object-based
programming systems. Squeak comes to mind as a simple target for this idea,
although they're not aiming for this aspect themselves.

But database theory itself is relatively poor in its applicability to Tunes
in that it's almost entirely about implementation of large-scale uniform
object stores. I thought that the whole point of Tunes was to allow more
flexibility in meta-data than any database ideas could ever hope to achieve.

The Tunes mailing list gets a lot of posts from people who have recently
joined the group and have ideas to share, but the quality of those ideas
should be measured by how well they relate to the edification of the ideas
promoted by the Tunes documentation (what little there is of it). If you
can't explain why database theory does anything more for Tunes than does
something like the idea of persistent hyperprogramming within Napier88, or
doesn't already have an obvious embedding into an existing high-level
unified programming language like Lisp or Smalltalk, then the discussion
has nothing to do with Tunes.

~