Re: Storing data and code in a Db with LISP-like interface

From: x <x_at_not-exists.org>
Date: Tue, 4 Apr 2006 10:12:14 +0300
Message-ID: <e0t67r$hqj$1_at_emma.aioe.org>


"Neo" <neo55592_at_hotmail.com> wrote in message news:1144111042.600878.64360_at_i39g2000cwa.googlegroups.com...

> I agree with you that RMDBs are not structurally dynamic enough,
> especially at run-time, to be successful in some scope of applications
> (including AI-type). Dynamicity is a not a limiting factor with the
> expermental db. It not only provides generic storage of data that is
> independent of how it is used, the supporting structure is very
> flexible and can be modified at run time (by among other things,
> execution of code stored in the db). Part of this flexibility arises
> from a data model based on nodes where each can connect to any other
> node, and not on relations which requires the same attributes for every
> tuple defined at design-time. Note that nodes can be arranged to
> function as *lists, tables, trees, circles, graphs, networks*, etc but
> this flexibility comes at the cost of memory and processing time. Also
> user does not arrange the nodes directly. The db does it automatically
> by processing the user's high-level instructions such as (create john
> gender male).

It does not matter if you picture data as *lists, tables, trees, circles, graphs, networks* .
The only thing that matters is what operators do you have. You can picture a relation in any way you like but ultimately it is the algebra or calculus that counts.

> If you would specifiy a simple example that would demonstrate the
> offending "impedance mismatch" between programming and RMDBs, I can try
> to show a possible solution using C and the experimental db (the
> LISP-like interface is still in its early stage of dev).

This is because C is an imperative language for which the *layout* of the data is more important than the content when used by some programmers. :-) Received on Tue Apr 04 2006 - 09:12:14 CEST

Original text of this message