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

From: topmind <topmind_at_technologist.com>
Date: 17 Apr 2006 21:20:15 -0700
Message-ID: <1145334015.526492.82650_at_j33g2000cwa.googlegroups.com>


Neo wrote:
> TopMind, you understandably have some misperceptions about the
> experimental db. The best and sometimes the only way to clarify them is
> to actually represent some things and compare the process and results.
> Would you be willing go thru this process with me? It requires you to
> post SQL script to represent some things and perform some queries. It
> isn't my goal to embarass anyone, but simply to compare the two
> methodologies, each of which have strong points and weakness that make
> them appropriate for different scopes. I am not concerned about trivial
> matters such as naming conventions\, punctuation, style, obvious
> omissions, simple errors, etc. I am able to email you a small zip file
> (200Kb, 1/7th of a floppy) for verification, if requested. It contains
> the script to create db, db file and db executable. The program
> requires no installation. Just double-click to run. Throw in trash when
> done.
>
> During the pask week, I have posted the following examples:
> 1) People in multiple matrix hierarchies and getRoot function.
> 2) Judges, bailiffs, clerks, etc in various parts of court building.
> (see thread titled "Data Model")

My version is at:

http://www.c2.com/cgi/wiki?CourtRoomSchemaExample

[....]

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

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.

> > As far as dynamic schemas, you have yet to back your claim that they are inharently inefficient.
>
> 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.
>

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

-T- Received on Tue Apr 18 2006 - 06:20:15 CEST

Original text of this message