Re: Storing data and code in a Db with LISP-like interface

From: Neo <>
Date: 15 Apr 2006 14:15:13 -0700
Message-ID: <>

>> [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. Received on Sat Apr 15 2006 - 23:15:13 CEST

Original text of this message