Re: MultiValue Databases

From: Neo <>
Date: 9 Jun 2005 18:21:39 -0700
Message-ID: <>

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

What I tried to demonstrate, albeit in one simple example, is that a more general data methodology (ie xrdb) is less affect by new requirements.

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

Neither the initial xrdb or RM db was developed in a chaotic fashion. They were both designed appropriately for the data/queries known initially. If you disagree, please post script for db that you would consider to be non-chaotic for the initial data/queries specified.

> It would be EVEN quicker to store the data in one big text file.

True but it is neither the goal of xrdb or RM to store data quickly at the expense of sacrificing data integrity and managability.

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

Using the above criteria, I could not prove that RM is more general than store data using a text editor.

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

It seems you haven't been involved in projects where the requirements keep changing with time? May I ask your field of work and if your position is more similar to a manager or a software developer? AI-type applications frequently face new requirements on-the-fly. The ultimate example are the millions of databases located in the brains of various animals on earth that are continously adapting to new information in a piecemeal fashion.

> Just from thinking about it, xrdb can be shown as better than relational
> databases when it comes to storing data or completely unpredictable structure.

Yes, that is a scope where xrdb should be appropriate. I have suggested it for AI-type apps and this usually bring the news group to it's knees (in laughter :)

> The problem is that someone has to retrieve that data,
> enforce integrity constraints on it etc.

What problem retrieving data? Like finding a person with two phone number in RM? Data integerity is provided at xrdb-engine level. Constraints have to implemented in user's application currently (see response to Ed's similar post). Currently the integration of constraints in RMDBs is much superior.

> 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 [is nightmarish].

It is obvious you have not browsed the same data in RM and xrdb? xrdb can view it's data in either a tree or table and user does not perform any joins. The equivalent data in RM requires user to perform joins and create views. See tree in figure at for a view of the simple phone# example. For complex and highly variable data structures, the difference is quite significant! Try modelling and then creating views for the property listing shown in a tree at or the 10 computer systems shown at

> trying to write queries for it, reason about the structure,
> compare different entities etc could be nightmarish.

Consider the below queries to find a person whose phone number is 111-1111 and 222-222 in xrdb and RM using the initial simple schema. Note that one has yet to post the equivalent query using the update schema. Note that the xrdb's original query did not change even ater accommodating the new data. Also note, some of the slightly more complex xrdb queries haven't been answered in RM. I do acknowledge that overall, SQL is much more complete/powerful (currently).

// xrdb query
(SELECT * phone# 111-1111 & * phone# 222-2222)

// RM query
FROM person,

WHERE        person.personID = person_phone.personID
AND    person_phone.phoneID  =        phone.phoneID
AND phone.number = "111-1111"
FROM person,
WHERE        person.personID = person_phone.personID
AND    person_phone.phoneID  =        phone.phoneID
AND phone.number = "222-2222"

Which of the above looks "nightmarish"? Received on Fri Jun 10 2005 - 03:21:39 CEST

Original text of this message