Fog Creek Software
Discussion Board


In my opinion there are three kinds of databases:
- oltp (relational)
- olap (cubes)

(I'm looking for another term for the xml one, because that's just an implementation issue)

Some justification:

The XML database lends itself for heterogeneous data, where relational databases do not. Relational databases tend to be complex if there are some exceptions (like just one customer with more than one address). XML can handle exceptions quite nicely without getting to complicated.

Some applications, like patient files, contact info, are suited for XML storage. This data is hierarchical in nature; contact at the top and all child data as branches.

Oltp databases are focused on transactions (write operations), where XML databases are focused on retrieval operations.

- Is the partitioning in three kinds of databases justified?
- Am i missing other kind of databases? For example, how do messaging systems fit in (JMS, MS Queue, etc) ?

Any ideas/suggestions would be appreciated.

Stephan Westen
Wednesday, January 23, 2002

I would use the term "hierarchical database" instead of "xml database" because it is the tree structure of xml, that you focus on. If you in your "xml database" zoom out a little you will see the hierarchical structure continue in the filesystem and here you have your message system (MS Queue, smtp, nntp - mayby not all that "queuey", but...).

(I always find myself implementing the hierarchical structure ind a rdbms for cms'es)

Wednesday, January 23, 2002

A relational database suits itself well to hierarchical data, or almost any data structure for that matter.

The reason why relational databases were invented was to overcome the limitations of hierarchical databases in the first place

Have a read of this also, it's quite funny!

Matthew Lock
Wednesday, January 23, 2002

Heirarchical databases also continued to be developed into Network databases, keeping the heirarchical structure but allowing recursive sets and multiple parents.  MDBS Inc still produce a database which can be presented as either a relational, network or object database.

Relational operations become very expensive the more complicated the join, network databases maintain the same level of complexity regardless of the query but pay for that by having a static data dictionary that is difficult to change without rebuilding the entire database.

Simon Lucy
Thursday, January 24, 2002

You also seem to have missed object databases in your taxonomy.

In fact, I think you're probably confusing several levels of analysis here. Tables, XML, object-oriented are database technologies. Relations, hierarchies, cubes are high-level ways of organizing data. You can, for example, cram a hierarchy into most any database technology with enough effort. The question then becomes how do you choose hte most appropriate technology for your data? And you need to consider not only which low-level data structures map best to that data, but also product cost, support, interface...

Mike Gunderloy
Thursday, January 24, 2002

And then there's deductive databases...

Paul Brinkley
Thursday, January 24, 2002

I checked out that link on ArsDigita, Matthew.  It's going into my bookmarks file now.  Great, great stuff.

Paul Brinkley
Thursday, January 24, 2002

Do people really think about this? Who cares? Just learn SQL and get over it...

El Grumpo
Thursday, January 24, 2002

Ha-Ha! "Learn SQL!" Tsnot enough to learn SQL to know what databases are. Though Joel does not seem to like "architectural austronauts" but I am sure that clear understanding of the data structures, presentations, and technologies that were and are used is crucial to the successfull application development. The "learn SQL" approach leads to the applications that perform only 2 online registrations per minute!

Nice topic. I learned a couple of new things from here :)

Sinclair Evilguest
Sunday, January 27, 2002

*  Recent Topics

*  Fog Creek Home