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

Neo wrote:
> > > Neo: It is true that for some scope of problems, relational query views don't work well, but I suggest that dbs [not RMDBs] and programming can eventually be combined seemlessly. After all, that is what human brains have been demonstrating for some time.
> .
> > TopMind: Lahman and I have had a long-running disagreement about the usefulness and limits of relational technology. If one learns how, large parts of most applications can be "farmed off" to the database IMO such that more of the app is attribute-driven rather than code-driven.
>
> Both you and Lahman are partially correct. Lahman is correct in that
> dbs based on RM cannot provide the type of flexibility required for
> some applications but he is wrong that it can't ever be done with any
> db. You correct in that farming as much data (in fact I would include
> code when that becomes practical) as possible into the db would make an
> app more flexible, however this isn't and will never be practical for
> more complex type of applications using RMDBs.

What is an example? Some processes don't lend themselves well to relational techniques, but it is not necessarily due to "complexity".

> Overall, I find your
> posts indicative of a broad-minded person.
>
> > Relational does not *have to* be static: www.geocities.com/tablizer/dynrelat.htm
>
> Thanks for the link. The blog's author is voicing his gripe against the
> static nature of RMDBs and wishes they were more dynamic, especially in
> terms of data types, columns and even tables. While his wish list is
> what many of us want, what he doesn't realize is that those wishes are
> mostly impractical to implement in the context of RM.

Why is that? I agree it would probably be somewhat slower than a static version, but not anymore than interpreted languages being slower than compiled ones.

> It's like wishing
> your '57 Chevy were as fast and agile as a Corvette. While not
> impossible, it is highly impractical.
>
> > Why existing vendors don't offer dynamic options, I don't know. The closest thing I know is SqLite, but it only has dynamic cell types, not dynamic column creation.
>
> It is due to the Relational Model itself. The best way to verify this
> is to actually write the code for a db with dynamic features as
> described! The complexity/impracticality of doing so is not readily
> evident until one does.

I would like an example of a rough point.

-T- Received on Sat Apr 15 2006 - 08:23:42 CEST