> I think it a huge 
> conceptual mistake to make document computing the centerpiece 
> of database design although it is a big win for the GUI.

It certainly can be a big mistake. I think there are two cases where it
works well:

(a) where the documents map well to the business objects that are the
primary information content of the database. For example a database of
hotels can work well when implemented as a database holding one document per
hotel, similarly a database of medicinal drugs. You get issues about where
to put information that doesn't belong directly with a hotel (e.g.
information about a hotel chain or about a resort), but if you're clever you
can present this to viewers (not updaters) as if it's just part of the hotel
information. (One thing that seems to be lacking from most of today's XML
databases is this concept of a persistent virtual document or view.)

(b) where the purpose of the database is to record events and the events are
captured by documents - for example safety inspection reports or insurance
claims. In this situation a database of documents is exactly what you need.

When these conditions don't hold, for example with an HR database, despite
the fact that XML is very good at handling the flexibility of the data,
document-centred modelling certainly has its limitations. But then so do
other modelling techniques. I once asked a data modelling class to model a
railway timetable - big mistake.

Michael Kay
http://www.saxonica.com/