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

Neo wrote:
> > > Neo: Let me qualify what I mean by "storing code in a db". The code must be stored in its elemental form (not as a chunk or blob) and can be created, selected, updated, deleted, etc ... using its standard Data Manipulation Language (DML)?
>
> > Lahman: I'm afraid I can't buy the utility. Databases, the RDM, and normalization exist to provide generic storage of data that is independent of how it is used. The supporting structure is inherently static.
>
> I agree with you that RMDBs are not structurally dynamic enough,
> especially at run-time, to be successful in some scope of applications
> (including AI-type). Dynamicity is a not a limiting factor with the
> expermental db. It not only provides generic storage of data that is
> independent of how it is used, the supporting structure is very
> flexible and can be modified at run time (by among other things,
> execution of code stored in the db). Part of this flexibility arises
> from a data model based on nodes where each can connect to any other
> node, and not on relations which requires the same attributes for every
> tuple defined at design-time. Note that nodes can be arranged to
> function as lists, tables, trees, circles, graphs, networks, etc but
> this flexibility comes at the cost of memory and processing time. Also
> user does not arrange the nodes directly. The db does it automatically
> by processing the user's high-level instructions such as (create john
> gender male).

Relational does not *have to* be static:

http://www.geocities.com/tablizer/dynrelat.htm

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.

>
> > Programming languages, OTOH, are designed to describe the dynamics of very specific problem solutions. IOW, program code uses data in a very particular fashion and the resulting structure is designed to be fluid. I see that as a fundamentally different and incompatible paradigm.
>
> Again, I agree with you that existing db methodologies (including RM)
> have the above described limitation; however, the experimental db
> allows "fluid" data structures.
>
> > One manifestation of that difference is that programming languages can express the solution much more compactly than your elemental code.
>
> While a particular programming language may or may not express the
> solution more compactly (which isn't important in my case), it will not
> likely have the flexibility (which is important in my case). In my
> estimation, making it as flexible will require more code than in my
> solution. But I can't verify your assertion until someone actually
> posts an alternate solution and we compare their flexibilities,
> especially handling things/hierarchies not specified at design time.
>
> > That's why one needs step stone languages like SQL to map between the paradigms. It is also why all programming languages separate data from the operations on data syntactically.
>
> Again I agree with your overall assessment of the current "impedance
> mismatch" between programming languages (esp OO) and existing dbs. I
> believe the experimental db resolves some of the mismatch and retains
> some of the benefits of RM.
>
> > If one is going to think of problem solving solely in terms of relational database queries, then the RAD IDEs already provide that for CRUD/USER processing at a much higher level of abstraction where one barely needs to have code at all.
>
> Luckily, most people (esp in c.d.t) haven't accused me of solving
> problems solely in terms of relational db queries.
>
> > But for larger and more complex problems where the UI and DB are peripheral considerations, that relational query view does not work well at all -- which is why we have procedural, OO, and functional programming.
>
> It is true that for some scope of problems, relational query views
> don't work well, but I suggest that dbs and programming can eventually
> be combined seemlessly. After all, that is what human brains have been
> demonstrating for some time.

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.

>
> If you would specifiy a simple example that would demonstrate the
> offending "impedance mismatch" between programming and RMDBs, I can try
> to show a possible solution using C and the experimental db (the
> LISP-like interface is still in its early stage of dev).

-T- Received on Wed Apr 12 2006 - 22:56:57 CEST