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

From: Bob Badour <>
Date: Mon, 17 Apr 2006 20:07:26 GMT
Message-ID: <2AS0g.61404$>

Nick Malik [Microsoft] wrote:

> "Bob Badour" <> wrote in message
> news:ieu0g.60832$

>>Neo wrote:
>>>>Prolog also uses linked lists which can be nested. In addition, you can 
>>>>place structures in the list, and the structures can contain atoms and 
>>>>lists and "lists of lists" and "lists of lists and atoms," etc.  There is 
>>>>no 'program.'  The system is an ordered database of assertions.  You 
>>>>start the logic engine by asking a question. The engine attempts to 
>>>>answer the question using the information in the database, matching as it 
>>>>goes, using a depth-first tree search.  The underlying math is predicate 
>>>>calculus and horn clauses.  Primitives in the language allow you to 
>>>>assert data into the database, thus modifying the 'program'.  This allows 
>>>>the system to learn.
>>>the focus of the experimental db is to provide the most flexible
>>>method of representing things. I believe I have already surpassed RM.
>>Idiot. Complexity of structure is not a worthy or useful goal in data 

> Hi Bob,
> The first quote, above, is an excerpt from my post, not Neo's post. So you
> are clearly calling one of us an idiot. Not sure who. :-)
> I agree that complexity of structure is not a worthy goal. Never said it
> was. Nor, to the best of my knowledge, did Neo.

With all due respect, Neo did. When Neo says: "the most flexible method of representing things" and compares it to the RM, he uses "flexible" as a synonym for "complex" and "method of representing things" as a synonym for structure.

I have no objection to your factual description of the Prolog programming language. The RM says nothing about programming languages in any case.

> On the other hand, if the
> data itself is complex, it's representation should be a simple as possible,
> but no simpler.

Relations are that structure.

> I've seen overnormalization ruin a perfectly good database.

Your statement suggests neither you nor the person who "ruined a perfectly good database" understood normalization in the first place.

Arbitrary decomposition by project and join has nothing to do with normalization.

> Prolog is not an inherently type-safe language. There is no SQL language to
> assert the data into Prolog's database. These are probably weaknesses,
> although I'm not sure I've experienced them as such, because the 'database'
> in a Prolog system is the database of rules that drive the engine, and that
> database should change slowly, and in a very controlled manner. Don't
> confuse logic management with data management.

I don't, which is why I have no objection to anything you said about Prolog. It is not a database management system, but a programming language. The RM has nothing to say on that subject as it is entirely orthogonal to data management. Received on Mon Apr 17 2006 - 22:07:26 CEST

Original text of this message