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

From: Neo <neo55592_at_hotmail.com>
Date: 13 Apr 2006 16:21:20 -0700
Message-ID: <1144970480.735546.107610_at_i39g2000cwa.googlegroups.com>

> > Neo: It is true that for some scope of problems, relational query views don't work well, but I suggest that dbs [not RMDBs] and programming can eventually be combined seemlessly. After all, that is what human brains have been demonstrating for some time. .
> TopMind: Lahman and I have had a long-running disagreement about the usefulness and limits of relational technology. If one learns how, large parts of most applications can be "farmed off" to the database IMO such that more of the app is attribute-driven rather than code-driven.

Both you and Lahman are partially correct. Lahman is correct in that dbs based on RM cannot provide the type of flexibility required for some applications but he is wrong that it can't ever be done with any db. You correct in that farming as much data (in fact I would include code when that becomes practical) as possible into the db would make an app more flexible, however this isn't and will never be practical for more complex type of applications using RMDBs. Overall, I find your posts indicative of a broad-minded person.

> Relational does not *have to* be static: www.geocities.com/tablizer/dynrelat.htm

Thanks for the link. The blog's author is voicing his gripe against the static nature of RMDBs and wishes they were more dynamic, especially in terms of data types, columns and even tables. While his wish list is what many of us want, what he doesn't realize is that those wishes are mostly impractical to implement in the context of RM. It's like wishing your '57 Chevy were as fast and agile as a Corvette. While not impossible, it is highly impractical.

> Why existing vendors don't offer dynamic options, I don't know. The closest thing I know is SqLite, but it only has dynamic cell types, not dynamic column creation.

It is due to the Relational Model itself. The best way to verify this is to actually write the code for a db with dynamic features as described! The complexity/impracticality of doing so is not readily evident until one does.

While not fully implemented, the experimenal data model greatly reduce the existing impedance mismatch. Below I show how the experimental db can create the equivalent of tables, columns, and values of various types dynamically at run-time. The same script can be created/executed by C at run-time. A more programmatic method (various functions) is also available to accomplish the equivalent of the script from C at run-time via a DLL. All my prior examples can also be created dynamically but it just doesn't seem to register.

The script below creates a person named John (think of him as a judge on a food panel). It then adds the attribute/column "likes". It then create three new types to classify food entries. The first entry is named leftOver1. The second entry is a fruit named apple1. The third entry is a vegetable named broccoli1. The fourth entry is a fruit/vegetable named tomato1. The script demos several queries to find which things John likes based on type(s).

Note that, while the script seems simple making people wrongly conclude that experimental db is nothing but a word processor, each simple looking word actually translates into a fairly complex query requiring a db schema and lengthy query which would quickly becomes impractical in RM. In addition the data in the db fully normalized and NULL-less. If the db had multiple things with the same name the expressions would become more elaborate.

// Create type person.
(create type instance (new))
(create (it) name (findElseAdd name instance 'person'))

// Create person instance.
(create person instance (new))
(create (it) name (findElseAdd name instance 'john'))

// Create the attribute/column "like" and classify it as a verb.
// Note: Unlike RM, where each attribute is attached
// to every tuple in a relation, in the experimental db
// the attribute is attached to things on an individual basis.

(create verb instance (new))
(create (it) name (findElseAdd name instance 'like'))

// Create type [food] entry.
(create type instance (new))
(create (it) name (findElseAdd name instance 'entry'))

// Create an entry named 'leftOver1'.
(create entry instance (new))
(create (it) name (findElseAdd name instance 'leftOver1'))

// Create type fruit.
(create type instance (new))
(create (it) name (findElseAdd name instance 'fruit'))

// Create a fruit entry named apple1.
(create entry instance (new))
(create fruit instance (it))
(create (it) name (findElseAdd name instance 'apple1'))

// Create type vegetable.
(create type instance (new))
(create (it) name (findElseAdd name instance 'vegetable'))

// Create a vegetable entry named broccoli1.
(create entry instance (new))
(create vegetable instance (it))
(create (it) name (findElseAdd name instance 'broccoli1'))

// Create a fruit/vegetable entry named tomato1.
(create entry instance (new))
(create fruit instance (it))
(create vegetable instance (it))
(create (it) name (findElseAdd name instance 'tomato1'))

// Create john likes lefover1.
(create john like leftOver1)

// Create john likes apple1.
(create john like apple1)

// Create john likes broccoli1.
(create john like broccoli1)

// Create john likes tomato1.
(create john like tomato1)

// Find which entries john likes.
// Either of the below expressions
// displays leftOver1, apple1, broccoli1, tomato1
// in 4 consecutive dialog boxes.

(msgbox (select john like *))
(msgbox (and (select john like *)

             (select entry instance *)))

// Find which fruit entries john likes.
// Displays apple1 and tomato1.
(msgbox (and (select john like *)

             (select fruit instance *)))

// Find which vegetable entries john likes. // Displays broccoli1 and tomato1.
(msgbox (and (select john like *)

             (select vegetable instance *)))

// Find which fruit/vegetable entries john likes. // Displays tomato1 in a dialog box.
(msgbox (and (select john like *)

             (select fruit instance *)
             (select vegetable instance *)))

If someone is interested in what the above actually looks like when viewed in the db's exe, I can email it (script, db file and db exe fit on a single floppy). Received on Fri Apr 14 2006 - 01:21:20 CEST