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

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- Received on Sun Apr 16 2006 - 08:20:30 CEST