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

> > 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).

> 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.

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). Received on Tue Apr 04 2006 - 02:37:22 CEST