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

From: topmind <topmind_at_technologist.com>
Date: 20 Apr 2006 21:47:17 -0700
Message-ID: <1145594837.716402.16800_at_v46g2000cwv.googlegroups.com>


Neo wrote:
> >> Partial Grid View of Person Instances:
> >> ID name phone# email staffMember
> >> -- --------- -------- ------------- -----------
> >> # judy 333-5555 j..._at_aol.com clark
> >> # clark 737-5588
> >>
> >> Partial Tree View of Person Instances:
> >> -Person
> >> |-instance-
> >> |-Judy
> >> | |-phone#-
> >> | | |-333-5555
> >> | | |-JDG-JUDY
> >> | |
> >> | |-email-
> >> | | |-J..._at_aol.com
> >> | | |-J..._at_law.com
> >> | |
> >> | |-staffMember-
> >> | |-Clark+
> >> | |-Ashley+
> >> | |-Colby+
> >> | |-Brandy+
> >> | |-Courtney+
> >> |
> >> |-Clark
> >> | |-phone#-
> >> | | |-737-5588
> >> | |
> >> | |-assistant-
> >> | |-Ashley+

> >
> > 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 Relation Data Model is more general/flexible
> than the Hierarchal Data Model.


"Navigational" is a superset of hierarchical. Generally there is the Network model and Hierarchical model. Yours is a kind of hybrid, 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.

-T-

> The advantage of a more
> general/flexible method (RM) is that its scope it larger. The advantage
> of a more specialized/limited method (HM) is that it is more efficient
> within its smaller scope. (This might sound familiar as I have been
> repeating this for several years now :)
>
> However, to assume the underlying data model based on a particular view
> is unreliable. In hierarchal model, it is impossible to represent a
> thing with more than one parent without redundancy. If you were to
> click around in exp db's tree view, with option to display each thing's
> ID enabled, you would see that while a thing is a child in multiple
> hierarchies, it still has the same ID. For example, most of the persons
> in the example have multiple classifications, yet when one drills down
> Person, StaffMember or Clerk instances, Clark has the same ID! The same
> can be verified with this thread's original example where Adam is in
> the parent/child and boss/employee hierarchy. If you change Clark's or
> Adam's attributes or atribute values in one hierarchy, it shows up in
> the other hierarchies as well, without the db engine having
> synchronized data in multiple places. (Note that tree nodes in GUI may
> need to be refreshed by closing/opening its parent tree node)
Received on Fri Apr 21 2006 - 06:47:17 CEST

Original text of this message