Re: MultiValue Databases

Neo wrote:
> Again, thanks for posting RM script to allow a comparison. As
> indicated, one needs to use a different RM schema to support the
> additional data/queries requested after the initial db/schema was
> completed.

Yes. That's because the requirements change. You model based on requirements. If the requirements change, you re-model.

  Also, in some circumstances, one might need to either move
> the original data to new db or update existing db rather then recreate
> the entire db from scratch. Notice that xrdb did not require such
> changes to accommodate additional data/query in this particular case. I
> am proposing that this results from xrdb's data model being more
> general than RM.

If you develop a database in a chaotic fashion with the structure of the data rapidly changing, then development using xrdb will usually be quicker. It would be EVEN quicker to store the data in one big text file.

To prove that the data model is "more general" does not require examples ad nauseam, it requires proof. If you can... a) provide an example of information that cannot be stored using the relational model and can be stored using xrdb AND b) prove that there is no information that can be stored using the relational model that cannot also be stored in xrdb, then you can justify your claim.

I am aware that one cannot draw such a definitive
> conclusion from one trivial example (my conclusion in based on my
> understanding of both models). In fact, Lee suspects that I rig the
> examples to my advantage.

I sympathise with Lee. These examples bear no resemblance to a real-world modelling task that I have encountered, simply because one normally works from a known spec rather than designing a few tables and adding extra information in a piecemeal fashion.

I propose that a neutral party specify some
> data requirements and then add/modify them in several stages and see
> how xrdb and RM handle them. In the past, I suggested example 123
> (www.xrdb.com/example/default.asp). It models 10 computer systems, each
> quite different. Once someone posts a script for the first 10, a
> neutral party can specify more, each being different than the prior,
> each being known only after the prior has be stored in order to show
> how the two models handle schema evolution. Example 117 (Property
> Listings) would also be another good candidate to highlight db
> flexibility and schema evolution.

This just isn't the way that you prove a point. You need to do it in an abstract and formal way rather than by these examples, usenet challenges etc.

I admire your enthusiasm for your cause, and am very much a supporter of new technologies, the underdog etc. If you are serious about this then get up to speed on the relational model and the supporting theory (read and absorb the whole of Date's intro to database systems for example). This will introduce you to the whole range of criteria against which a database will be judged. If xrdb is going to compete, it will have to be as good as or superior to relational DBMSs in every criterion. Like it or not, relational databases are the market leader and you'll have to know them inside out for your product to compete with them.

Just from thinking about it, xrdb can be shown as better than relational databases when it comes to storing data or completely unpredictable structure. Your computer task would probably show that xrdb was neater for persisting this type of information. The problem is that someone has to retrieve that data, enforce integrity constraints on it etc. With a relational DB you can see a list of tables each of which contains atomic or encapsulated values and has regularly defined constraints on it. Trying to browse the xrdb hierarchy looks complicated enough using the tool you have developed; trying to write queries for it, reason about the structure, compare different entities etc could be nightmarish.

If I were you I would think about / do the above then produce an advocacy paper with formal justification for each of the claims. Post back here and I'm sure a lot of people will assess it for you. I am not a big one for ad hominem arguments, but I think you need to realise that you need to be very well-educated and experienced in this field to avoid looking like a tit compared with people that are. I hasten to add that I profess to be neither.

John Received on Wed Jun 08 2005 - 18:27:20 CEST