Neo wrote:
> >> [some complex apps will never be practical using RMDBs]
> .
> > [complex?] What is an example?
>
> The example like the one in the post that you just responded to that
> creates the equivalent of tables, attributes and values of
> various/multiple new types at run-time. The example like the one given
> in response to Roy Hann earlier in this thread which creates a
> parent/child hierarchy with multiple things, then creates a function
> named getRoot(hier, thing) stored in db itself, then creates a second
> boss/employe hierarchy using some of the same things in parent/child
> hierarchy and then verifies getRoot still works with both hierarchies;
I find that trees don't model real organizations very well. Having
multiple bosses is fairly common. (Known as "a matrix organization" in
some co's) If you want flexibility, then have a many-to-many Boss (or
ReportsTo) table.
> and even works after adding a person without a name in the hierarchy;
> and still works when we allow the name employe to have a second
> spelling 'employee'; and still works when boss is given an alternate
> name employer; ALL AT RUN-TIME, without the user ever having to specify
> a schema, IDs, referential intergrity constraints or normalizing data,
> yet the db is fully normalized and NULL-less!!!
If the user can change the schema willy-nilly, then there is no way on
earth technology can enforce normalizaton (short of AI) because it
cannot know if two things with a different name are really the same
thing in practice. It would have to have common sense.
Further, a Lisp DB cannot be shared with other languages. One of the
advantages of a RDBMS is that different languages and tools can all use
the *same* database. Unless you want to turn Lisp into a query language
(ick!), that won't happen.
>
> In general, the complexity starts to become apparent when one tries to
> create an initial RM schema that will allow it to store any data, whose
> structure is unknown at design-time and only known at run-time and all
> data is to be normalized, NULL-less and have referential integrity
> enforced. Please see recent thread titled "Multiplicity, Change and MV"
> which discusses a similar topic.
Nulls are a vendor-specific idea, not inherent to relational.
>
> >> dynamic [stuff] impractical to implement in the context of RM.
> .
> > Why is that?
>
> The right wrench (schema) is hard to pick in advance for a nut (data)
> whose size (structure) is unknown until encountered out in the field
> (run-time) at the tippy-top of a tall antenna tower in Timbuktu. With
> RM, the service man (developer) has to return to the workshop
> (design-time) to get the right size wrench (new schema) for the job. My
> data model allows the equivalent of an adjustable wrench which adapts
> to the nut encountered in the field.
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.
As far as dynamic schemas, you have yet to back your claim that they
are inharently inefficient. Modern RDBMS don't store rows in
fixed-length segments anyhow. The technology for variable-length rows
already exists. I agree dynamic schemas may take up more space, but
that is not show-stopper compared to the alternatives. Either you
implement dynamic rows with vectors or maps. Maps are more flexible,
but take up more space. It is a trade-off to weigh against patterns of
change.
The idea of a "multiple paradigm database" can basically have one big
dynamic table, but it is essentially a navigational database in
relatioinal clothing:
http://www.c2.com/cgi/wiki?MultiParadigmDatabase
A navigational database is like a shanty town: no guidence and no
rules. Yes, it is flexible because if you need something, you simply
hammer it on. However, it is a mess to navigate and manage.
No database paradigm will make changes in quantities-of-relationships
easy. For example, if a relationship changes from one-to-many into
many-to-many, this will be a mess regardless of whether you use
Bachman's techique or relational. If you go away from shanty towns,
some changes will indeed require time to revamp a building or two.
But the benefit is freedom from pure chaos. Nothng makes all changes
easier. Relational just makes the net cost of change easier in the
longer run. A shanty town may have fewer "change spikes" because it
changes incrementally. However, the total net cost is still higher
because even with change spikes, relational makes many other things
easier because it offers discipline and consistency over navigational.
-T-
|
