Re: Storing data and code in a Db with LISP-like interface
Date: 15 Apr 2006 14:15:13 -0700
Message-ID: <1145135713.211047.70880_at_e56g2000cwe.googlegroups.com>
>> [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!!!
>> dynamic [stuff] impractical to implement in the context of RM.
.
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
> Why is that?