Database Theory Links

[Kyle Lahnakoski]

"Brian T. Rice" wrote:

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

I agree with you.  I did not mean to say that DB theory was informed.  I
was trying to say that it models data well.  It needs some major fixes,
like self-joins to get better, and even then it is not a solution.  I am
in no way backing any DB vendor or implementation, especially SQL; only
the theory.



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

Is DB theory fundamental to a reflective system?  Apparently you do not
think so; maybe you're right.  Implementing my DBOS reflective system I
believe that any information stored in source code is hard to extract as
meta information.  You may have noticed my lack of enthusiasm for Joy
for just this reason.  To reduce code size I found it useful to
implement set operations, and the meta data to describe these
operations.  DB theory does this almost perfectly.  Now DBOS functions
are almost trivial because of the lack of loop structures.   


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

I worry you do not know DB theory well.  DB theory works orthogonal to
the classes that represent meta-data of a system, and does not
necessarily deal with "large-scale uniform object stores".  A simple 1-1
mapping between database tables and OO classes makes using a DB an
excellent alternative to memory.  Memory has many problems with respect
to its meta model.  Aspects such as physical size, object
location/pointers, correct allocation, and caching are complex.  DB
theory acts as a replacement for memory; it has well known meta classes
that describe its simple behavior.



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

To create a reflective system a model of it must be chosen.  That model
can be a simple stack, or a low level machine, or almost anything.  The
model need not be close to implementation, but the model must be able to
describe itself in terms of its own model.  I insist that a model is
necessary because I do not believe that any system can fully describe
its own implementation; it is the use of the model that makes a full
reflective system possible.  I tried to choose a simple model, and DB
theory helped in a particular aspect.






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