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

TopMind, while I wait for an updated RM schema, I am responding to earlier comments.

>>>> Neo: ... [exp] data model allows the equivalent of an adjustable wrench which adapts to the nut encountered in the field.
.

>>> TopMind: This battle was already faught between Charles Bachman and Dr. Codd in the 70's when navigational fought with relational. Bachman wanted ad-hoc "pointers" to build databases, while Codd felt that tables added more discipline to databases.
.

>> Neo: All I can say is that, I want you to evaluate based on actual results. When using the high-level interface, the user doesn't deal with IDs or pointers. You won't see either in the scripts also.
.

> TopMind: It is admittedly difficult to articulate why navigational structures are difficult to use. Let me try to put it this way: Knowing the "quantity of relationships" between the "nouns", most designers will come up with pretty much the same relational schema if they go to 3rd-normal-form. The differences will usually be minor between designers. The same is not true of navigational structures and thus there is no consistency. There are too many ways to do the same thing. They "work", but it takes a while to get your head around them because each has a different flavor and feel, often depending on the needs of a given app, whereas relational schemas (ideally) reflect information normalization, not usage patterns. Navigational structures are the "Goto's" of attribute structures: they "work", but are difficult to follow and inconsistent.

I think my response "All I can say ...", led you to believe that I agreed with Bachman/pointers over Codd/relational; when I really meant I don't have much knowledge or opinion on that topic. Now most people, when they hear that one of the exp db's interface is a tree view, they automatically think it is based on the hierarchal data model and therefore uses pointers. The exp db is not based on the hierarchal data model. It is based on a data model so general/flexible that it can do what the hierarchal model does (only not as efficiently within HM's smaller scope). Also I haven't discussed how the exp data model is implemented (and don't want to currently). Personally, the more one can abstract hardware dependencies, the better.

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

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

>>> Neo: blog's author is voicing his gripe against the static nature of RMDBs and wishes they were more dynamic ... what he doesn't realize is that those wishes are mostly impractical to implement...
.

>>> TopMind: As far as dynamic schemas, you have yet to back your claim that they are inharently inefficient.
.

>> Neo: I think it may be better for people who think dynamic schemas are practical in RM to implement it, than it is for me to explain further why it is impractical.
.

> TopMind: I would suggest giving a scenario that would allegedly be slower than yours.

It isn't a matter of speed as much as first figuring out how to make RMDBs dynamic at run-time. Currently, if an application is presented with certain new types of data at run-time, it is impractical to make the the app or rmdb smart enough to design the new appropriate schema, change existing schema with data, shift relevant data from existing tables to new tables and update related queries and code. With the exp db, the app simply stores the new type of data with less or no impact on existing queries and code! Received on Thu Apr 20 2006 - 22:29:43 CEST