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

> > > This is a typical structure of a "navigational" or "hierarchical" database. They are fine for particular specific uses, but over time people found they grew into messes and are hard to query for unforseen questiones. Dr. Codd was working with stuff like this when he felt there should be a better way.
.
> > Dr. Codd was right. The Relational Data Model is more general/flexible than the Hierarchal Data Model.
.
> "Navigational" is a superset of hierarchical.

It appears you are stating the above as a negative. Before I can counter it, I need to determine if the exp db is guilty of. Please precisely define what is "navigational" (with respect to representing things in a non-redundant manner in computers) and what is its disadvantage/limitation which the exp db should exhibit?

> Generally there is the Network model and Hierarchical model. Yours is a kind of hybrid,

Again, this is incorrect. It is not a hybrid (it's not the elephant's trunk + ears + tail, its the entire elephant). The exp's data model is more general than all the data representation methodogies/implementations including Hierarchal, Network, Relational, etc that can be used to create a db (ie runs on computers where the data is non-redundant, thus allowing for efficient data mgmt). This allows the exp db to accomplish what each of the less general methodologies/implementation can however not as efficiently within their practical scope. It can also do that which is outside the total combined scope of Hierarchal, Network and Relational Data Models.

The Hierarchal Data Model's significant limitation is, its inability to model things in multiple hierarchies without redundancy, which I have stated is not case in the exp db, since it can represent a thing in multiple hierarchies without reduncancy and have offered several ways to verify this including viewing a thing's ID in various hierarchies, etc.

Some limitations of the Relational Model are it forces constriants that are not always desirable for some apps (ie AI-ish). Believe it or not but requiring a schema and relation header prior to entering data are hardware-driven, data model-driven, user, app, etc constriants. Notice with exp db, not having these constraints does not prevent it from normalizing data (at run-time!) and from performing high level queries similar to SELECT statements found in SQL. In the exp db, constriants such as schemas and relation headers, if desired, can be stored in db like any other data, and can be enforced by the app (dbms will probably implement some basic/common constraints later).

Now the Network Data Model is a hybrid. Hybrid models ultimately suffer from complexity of implementation, usage, etc. Personally, the Network Data Model is a misnamed. It is more accurately named Hierarchal/Relational Hybrid Data Model.

One can hypothesize until end of eternity, but I prefer to prove/disprove things with actual implemetations. If one asserts that the exp db is a hybrid, please also try to specify a method that would verify such an assertion. I don't believe one is in a good position, to even make such assertions, until first demonstrating how to just model data (ie judge example) that can stored in the exp db with current methodogies which they feel are more general/flexible. Or have you already conceded this for RM? If the original data is too complex for RM to model practically, we can simplified it and continue with other considerations.

> but so were most (originally) hierarchical DB's in the 60's and 70's. IBM's hierarchical IMS had cross-links, and some file systems also have cross links, for example. Charles Bachman's databases were more network-based. (It should be pointed out that the DB's back then were not as dynamic as the newer incarnations, such as DOM.

If you believe DOM is more general/flexible than exp db, would you be able to verify this by actually representing/querying things (ie judge example). Received on Fri Apr 21 2006 - 18:03:19 CEST