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

> I would agree that [dbd's] approach makes it easier to get a report of all the varied stuff in or belonging to the courthouse. But in my observation these are not the most frequent kind of queries.

Your correct in that some queries are more common in a particular application. RM is more efficient in some scopes (more structured data). Dbd may do better in other scopes (highly unstructured data).

> Your approach seems optimized for a newbie to gain *general* familiarization of the area or a physical simulation, such as The Sims.

I'm gonna market it to dummies, someday :)

> But it does not appear well optimized for business-oriented queries, which are usually more focused in purpose. If this means that RM is optimzed for the biz world but not other domains, perhaps you have a point. But I have not really explored such outside of biz much, so cannot really comment. (It does remind me of DOM though, which I am not very fond of.)

There is a tendency (am I guilty of it too) for one to only recognize nails when one has been using a hammer for some time :)

> Usually report requests are more narrow in scope. For example, "What are all
the fixed assets in courthouse X that have not expired?" from the accounting department. They are not concerned with personel in there also.

If you'd like, I can add a second court house, some fixed assets (desks, chairs and computers) that belong to two departments occupying room(s) in courtHouse1 and room(s) in courtHouse2. To keep the example simple, I'll only add a name, serial# and a boolean expired attribute for each equipment. While dbd's queries cannot find sums or totals without the assistance of code at this time, the queries will be able to find the desired equipment. When such a query is executed from the GUI, dbd highlights the appropriate tree node in steps.

> Judge Judy? Isn't that a TV show?

:) Received on Sun Apr 30 2006 - 23:04:12 CEST