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

>>> Neo: method of representing things ... surpass[ing] RM. .
>> Bob: Complexity of structure is not a worthy or useful goal in data management.

> Marshall: Without necessarily endorsing Bob's general style of diction, I have to agree with him on this point.

Marshall, I haven't asserted that complexity of structure is a worthy or useful goal in data management.

> The easy part of data management is designing structures.

In depends on the application. For some apps, it isn't easy to design the structures. For an app where the data isn't known until run-time, please show the structures which allows the data to be stored and yet be queried/manipulated in a systematic manner (hint: it is possible, but highly impractical in RMDB). In this case, the app is something like an android.

> The hard parts are maintaining integrity and providing useful manipulations.

In the experimental db, referential integrity is automatic. All the LISP-like scripts that I have been posting, create non-redundant representation of thing in the db. Would you like to verify this? Currently user-defined constraints (all besides ref integrity) can be represented in db like any other data, but app code is responsible for enforcing them (sometime later, maybe some basic user-defined constraints may be executed by db engine itself).

> Flexibility in some ways is the opposite of structure; both provide benefits, but there is a significant degree of tension between the two. Simply maximizing flexibility doesn't lead to good design--that necessarily abandons all the value that structure provides.

Yes, I realize typically flexibility and structure are counter-balancing characteristics. And this is one of the reasons why the experimental db is revolutionary. It provides such flexibility that nothing the equivalent of a schema ever need be specified; yet at the same time allows querying and manipulation (a bit weak currently) of things as if data was highly structured!!! This is easy to verify. Look at the scripts and see that while no schema is specified, the queries (near the end of scripts) still work!

> One way this manifests in Neo's design is the kind of code he has to write to do retrieval; it's quite complicated, resembling more a turing-complete procedural language than a query language.

Ah yes, the "sledgehammer" analogy that no one has been able to verify by posting an RM solution that models the equivalent data and queries. If somebody ever does, it will be obvious that the "sledgehammer" actually applies to RM! Or will you be the first to prove your assertion? Is it my imagination that no one has post any solution using another methodology in nearly 100 posts! Marshall, are you willing to post SQL script for some of my examples and proceed to verify things? Received on Mon Apr 17 2006 - 03:52:42 CEST