Re: relational databases vs. not-so relational databases

"Mike Preece" <michael_at_preece.net> wrote in message news:1b0b566c.0201240907.61993d0e_at_posting.google.com...
> Interesting views Jan - and so much at variance with mine. Funny old
> world isn't it?

Well, it is a *discussion* forum, isn't it? :-) And opinions are nice, good arguments are better.

> I've been working with nested relational databases for years and have
> never yet encountered a DBA - there's simply no need for them.

The question is if that is because of the type of database you are using or because of the types of applications that you have experience with. The need for a DBA can arise when you have different groups of users with conflicting requirements. Do you have experience with such applications?

> I can
> testify that the claims made regarding simplicity and ease of use are
> merited.

I didn't deny them. I'm quite sure that for a system where all users are in agreement about how the data should be nested things become a lot simpler. But I'm also quite sure that for many companies with large amounts of data and many different types of users with different views upon this data this is not the case. So the claims by the authors are not completely false, but are also not true *in general*, and therefore should be qualified, i.e., it should be indicated under which circumstances they hold and under which circumstance they do not hold.

> Nested relational databases are also extremely flexible. We
> can easily extend the database, adding new fields on to records whilst
> the database is in use.

This is neither an inherent nor a unique property of the nested relational model.

> Typically there are certain data structures that are naturally nested.
> I can think of orders with one or more line-items, products with one
> or more parts, news groups with one or more threads, etc., etc.. It
> makes perfect sense to me for this nesting to be reflected in the
> database design. I don't accept that it is preferable to explicitly
> maintain the relationship. Why bother?

Because some users may want to nest the employees per department, whilst others would like to group them by type of function, and a third group of users would like a mixture of these two.

Kind regards,

• Jan Hidders