(Sorry for the semi-duplicate post; it was unintentional)
Neo wrote:
> > > > 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).
How does one objectively measure "general"? They are all potentially
representionally equivalent.
> 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.
Example?
>
> 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.
Please clarify. Dynamic relational is possible, as already pointed out.
> 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.
I would characterize it as a graph of nodes (records or maps), although
in practice it does tend to have a mix of trees and tables tendencies,
perhaps because people relate to tables and trees better than random
graphs.
>
> 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).
Unfortunately, there are not objective metrics, except perhaps
redundancy measurements. I could concede that it is purely a personal
choice. I like tables because they offer a consistency of design that
the other approaches don't. Tables are easy to visualize and
relational math is based on set theory.
Similar debates came up when Go To was challenged. The only things I
can come up with to describe the superiority of nested blocks is visual
cues (indentation) and more developer-to-developer consistency. Perhaps
if somebody do***ented "go-to patterns", they could have better defened
them. As it stands, visual-ness and consistency are the same reasons I
prefer relational over the other attribute-structuring techniques.
By the way, what would a query language look like for your suggestion?
Lisp?
-T-
|
