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

TopMind, it seems we are slipping back to an endless answer/question mode which spawns even more... Since I have asked serveral times, how you want to handle the shortcommings in the current RM schema to represent that in court judge example (which gets more difficult for various types of things in the has hierarchy) and not gotten a response, I suggest we put this one side and focus on the simpler food judge example which is well within RM's scope; however at least we can actually compare methodologies and I can extend that example to highlight some features and answer your questions. In addition, Nick has posted a Prolog based solution and this would be an excellent opportunity to compare three methodologies!

>> The exp's data model is more general than all the data representation methodogies/implementations including Hierarchal, Network, Relational, etc that can be used to create a db (ie runs on computers where the data is non-redundant, thus allowing for efficient data mgmt).
.
> How does one objectively measure "general"? They are all potentially representionally equivalent.

While it is theoretically possible for different data models to represent the same thing, one has to consider the practicality of doing so. Thus theoretically, the Hierarchal Model can represent the the same things as the Relational Model, however the further beyond Hierarchal Model's scope we get, the more impractical it becomes. Simlarly, it is theoretically possible for RM to represent court-judge-type examples, however they starts to become impractical. Factors that may be involved in measuring generalness are 1) when does the data model start to incur redundancies 2) when does the data model start to incur NULLs 3) when do the modelling methods change 4) constriants due to the model itself.

For example, the exp db's model has no schema constraints as required by RM. Just on this alone, it is probably IMPOSSIBLE for RM to ever be as general/flexible. In addition, RMDB implementations have additional hardware related constraints such as data types, where as the exp db does not. Exp db's generalness/flexibility and better abstraction of the hardware layer comes at the cost of resources such as memory, processing time, etc. (Note: even though the exp db's data model has no constraints and user does not specify a schema, this does not prevent the db from representing things in a non-redundant manner, which allows for efficient data mgmt - ie queries, updates, etc)

Because I know both the exp and RM data models, it is easy for me to see why exp data model is more general/flexible; however I don't not want to discuss it's details currently. An alternate way to measure the generalness/flexibility/scope of a tool is by verifying what range of problems/applications the tool is practical for.

For example, the scope/generalness/flexibility of a size 5mm socket, might be nuts from 4.95 to 5.05 mm. If we use a hammer, the socket might work from 4.9 to 5.1 mm but it is slightly impractical. Notice the method has changed, we now need to hammer. If we now use a sledgehammer and safety glasses, the socket might work for 4.8 to 5.2 mm. Notice the method has changed again.

With respect to a data models, generalness/scope/flexibility is the range of things that can be represented in a practical manner. For example, thus far the exp db examples have shown it can represent tables, hierarchies, matrixes and some variable structures. But I haven't yet seen anyone successfully represent data in exp db's court judge example.

> > This allows the exp db to accomplish what each of the less general methodologies/implementation can however not as efficiently within their practical scope. It can also do that which is outside the total combined scope of Hierarchal, Network and Relational Data Models.
>
> Example?

:) Allow user/app to enter data without specifying a schema yet the data is normalized which means it allows for efficient data management (ie queries, update, etc).

> > The Hierarchal Data Model's significant limitation is, its inability to model things in multiple hierarchies without redundancy, which I have stated is not case in the exp db, since it can represent a thing in multiple hierarchies without reduncancy and have offered several ways to verify this including viewing a thing's ID in various hierarchies, etc.
.
> > Some limitations of the Relational Model are it forces constriants that are not always desirable for some apps (ie AI-ish). Believe it or not but requiring a schema and relation header prior to entering data are hardware-driven, data model-driven, user, app, etc constriants.
>
> Please clarify. Dynamic relational is possible, as already pointed out.

Would you be willing to demonstrate it? Can it accept data without first entering/modifying a schema and yet the data is normalized?

> > Now the Network Data Model is a hybrid. Hybrid models ultimately suffer from complexity of implementation, usage, etc. Personally, the Network Data Model is a misnamed. It is more accurately named Hierarchal/Relational Hybrid Data Model.
>
> I would characterize it as a graph of nodes (records or maps), although in practice it does tend to have a mix of trees and tables tendencies, perhaps because people relate to tables and trees better than random graphs.

Unless one is able to relate data in any cell in any table to another data, including itself (as the exp db can), the "Network Data Model" falls quite short of being a graph of nodes (in my book).

> I like tables because they offer a consistency of design that the other approaches don't. Tables are easy to visualize and relational math is based on set theory.

And does this preference for tables, admiration for its consistency, ease of visualization in tables and relational math based on set theory  allow one to model the data in the court judge example? If so, please post schema and populate data so we can continue with other aspects. While exp db's methodology involves more steps (due to its generalness), the methods are consistent for describing trees, tables, multi-headed matrixes, etc. Notice in RM, methods changes for these situations. While table views are nice and exp db also has them, they are not very useful for tree and matrix like data. Even the tree is limited for complex matrixes and I hope to add an additional view to display them as nodes and links later.

> Similar debates came up when Go To was challenged.

I have no idea what goto's have to do with exp db. It seems I will have to go through another cycle of posts to tell you that whatever characteristics you are observing have nothing to do with goto; similar to earlier contentions that because the exp db displays data in a tree view (table views also available), it must be based on the hierarchal data model.

> By the way, what would a query language look like for your suggestion? Lisp?

Each example that I have posted has some at the end of the scripts, especially the food judge example. A simple query might be: (select thing1 attrib1 *).

Don't let it's simplicity fool you :) Received on Sun Apr 23 2006 - 02:54:27 CEST