>> [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;
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!!!
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.
>> 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.
|
