Re: O'Reilly interview with Date

dawn wrote:
> I just read the interview at
> http://www.oreillynet.com/pub/a/network/2005/07/29/cjdate.html
>
> My response:
> 1. He groups together an XML model and a semi-structured model. There
> is no way I would lump these two together. The mapping from the
> problem domain (subject area) to the model is very different between a
> "structured" and "semi-structured" approach. When we are talking about
> databases and dbms products, I would think that we are talking about
> structured data, not semi-structured. I'm aware of "XML databases"
> that could be used instead of a SQL-DBMS, while I'm not aware of
> semi-structured databases for the same purpose. Such systems would be
> more along the lines of a document management system, I would think.

I'm confused - you say you wouldn't lump them together, but the semi-structured approach you describe sounds like mainstream use of XML. How is XML different than the "semi-structured model"?

> Is there some other more common understanding of all of these terms
> that would prompt Date to lump an XML database into the same cateory as
> the Semantic Web, for example?

I'm not sure that

> Is it, perhaps, an effort to marry the already ensconced XML
> data model used at least for data exchange, to the not-exactly-stellar
> record of the semistructured efforts to date, hoping to disparage the
> xml model with this pairing?

Can you elaborate? I don't understand how "marrying" XML and semistructured requires much effort.

> 2. The way that these alternatives are tossed aside is by marrying the
> models to hierarchical and network and then dismissing those as having
> failed already. I realze you cannot put everything in an interview, but
> I have read quite a bit of Date's writings and haven't seem much more
> rationale than what is given here.

What are the major differences between XML and hierarchical, then?

> Is there a mathematical argument that shows why these approaches should
> be tossed aside as having nothing to offer?

Can you give a mathematical argument for tossing aside any approach at all in software? Perhaps you could define what you mean by "mathematical" in this context. The primary "soft" argument I'd use is that relations reduce complexity and enhance flexibility, while mirroring logic inherent in requirements ("business rules") more directly than prematurely and over-constrained O-O and hierarchical structures.

> Otherwise, this type of
> comment, similar to what is in most college database textbooks, is all
> I've got. The argument goes like this: We can model data based on
> language propositions using mathematical relations. There is no
> mathematically simpler way to model such data. Therefore, at the level
> of the logical data model, as well as the API to a dbms, there should
> only be mathematical relations and relational operators. This is
> clearly not a mathematical argument.

I'd call it something of a cousin of Occam's Razor, though perhaps there's a more formal argument a logician might use.

> Is there a better argument than that or is that it?

What would be?

> Thanks. --dawn
Received on Fri Aug 05 2005 - 18:08:43 CEST