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 relation****ps" 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, ****ft 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!
|
