Last month, ZDNet published an interview with MongoDB CEO Max Schireson which took the position that the document databases, such as MongoDB, are better-suited to today’s applications than traditional relational databases; the title of the article implies that the days of relational databases are numbered. But it is not, as Schireson would have us believe, that the relational database community is ignorant of or has not tried the design paradigms which he advocates, but that they have been tried and found, in many cases, to be anti-patterns. Certainly, there are some cases in which the schemaless design pattern that is perhaps MongoDB’s most distinctive feature is just the right tool for the job, but it is also misleading to think that such designs must use a document store. Relational databases can also handle such workloads, and their capabilities in this area are improving rapidly.

Let’s look at his example of entering an order into a database.  In this example, it is postulated that the order is split between 150 different relational tables, including an order header table, an order line table, an address information table and, apparently, 147 others.  Relational databases do encourage users to break up data across multiple tables in this way, a process callednormalization.  But not for no reason.  Storing every order in one large document may be ideal if all access will be strictly by order number, but this is rarely the case.  When a user wants to run a report on all orders of one particular product, an index on the order line table can be used to efficiently find and retrieve just those order lines.  If all order data is lumped together, the user will be forced to retrieve the entirety of each order that contains a relevant order line – or perhaps even to scan the entire database and examine every order to see whether it contains a relevant order line.

Read more at Robert Haas’s blog.