{"id":20474,"date":"2026-01-30T07:35:31","date_gmt":"2026-01-30T07:35:31","guid":{"rendered":"https:\/\/www.booksofall.com\/in\/?post_type=product&p=20474"},"modified":"2026-01-30T07:35:31","modified_gmt":"2026-01-30T07:35:31","slug":"readings-in-database-systems","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/in\/readings-in-database-systems\/","title":{"rendered":"Readings in Database Systems"},"content":{"rendered":"

Chapter 1: Background Introduced by Michael Stonebraker<\/a><\/h2>\n

I am amazed that these two papers were written a mere decade ago! My amazement about the anatomy paper is that the details have changed a lot just a few years later. My amazement about the data model paper is that nobody ever seems to learn anything from history. Lets talk about the data model<\/a> paper first.<\/p>\n

A decade ago, the buzz was all XML<\/a>. Vendors were intent on adding XML to their relational engines. Industry analysts (and more than a few researchers) were touting XML as \u201cthe next big thing\u201d. A decade later it is a niche product, and the field has moved on. In my opinion, (as predicted in the paper) it succumbed to a combination of:<\/p>\n

\u2022 excessive complexity (which nobody could understand)<\/p>\n

\u2022 complex extensions of relational engines, which did not seem to perform all that well and<\/p>\n

\u2022 no compelling use case where it was wildly accepted<\/p>\n

It is a bit ironic that a prediction was made in the paper that X would win the Turing Award by success- fully simplifying XML. That prediction turned out to be totally wrong! The net-net was that relational won and XML lost.<\/p>\n

Of course, that has not stopped \u201cnewbies\u201d from rein- venting the wheel. Now it is JSON, which can be viewed in one of three ways:<\/p>\n

\u2022 A general purpose hierarchical data format<\/a>. Anybody who thinks this is a good idea should read the section of the data model paper on IMS.<\/p>\n

\u2022 A representation for sparse data<\/a>. Consider attributes about an employee, and suppose we wish to record hobbies data. For each hobby, the data<\/p>\n

we record will be different and hobbies are fundamentally sparse. This is straightforward to model in a relational DBMS but it leads to very wide, very sparse tables. This is disasterous for disk- based row stores but works fine in column stores. In the former case, JSON<\/a> is a reasonable encoding format for the \u201chobbies\u201d column, and several RDBMSs have recently added support for a JSON data type.<\/p>\n

\u2022 As a mechanism for \u201cschema on read\u201d. In effect, the schema is very wide and very sparse, and essentially all users will want some projection of this schema. When reading from a wide, sparse schema, a user can say what he wants to see at run time. Conceptually, this is nothing but a projection operation. Hence, \u2019schema on read\u201d is just a relational operation on JSON-encoded data.<\/p>\n

In summary, JSON is a reasonable choice for sparse data. In this context, I expect it to have a fair amount of \u201clegs\u201d. On the other hand, it is a disaster in the making as a general hierarchical data format. I fully expect RDBMSs to subsume JSON as merely a data type (among many) in their systems. In other words, it is a reasonable way to encode spare relational data.<\/p>\n

No doubt the next version of the Red Book will trash some new hierarchical format invented by people who stand on the toes of their predecessors, not on their shoulders.<\/p>\n

The other data model generating a lot of buzz in the last decade is Map-Reduce, which was purpose-built by Google to support their web crawl data base. A few years later, Google stopped using Map-Reduce for that application, moving instead to Big Table. Now, the rest of the world is seeing what Google figured out earlier; Map-Reduce is not an architecture with any broad scale applicability. Instead the Map-Reduce market has morphed into an HDFS market, and seems poised to become a relational SQL market. For example, Cloudera has recently introduced Impala, which is a SQL engine<\/a>, built on top of HDFS<\/a>, not using Map-Reduce.<\/p>\n

More recently, there has been another thrust in HDFS land which merit discussion, namely \u201cdata lakes\u201d. A reasonable use of an HDFS cluster (which by now most enterprises have invested in and want to find something useful for them to do) is as a queue of data files which have been ingested. Over time, the enterprise will figure out which ones are worth spending the effort to clean up (data curation; covered in Chapter 12 of this book). Hence, the data lake is just a \u201cjunk drawer\u201d for files in the meantime. Also, we will have more to say about HDFS, Spark and Hadoop in Chapter 5.<\/p>\n

In summary, in the last decade nobody seems to have heeded the lessons in \u201ccomes around\u201d. New data models have been invented, only to morph into SQL on tables. Hierarchical structures have been reinvented with failure as the predicted result. I would not be surprised to see the next decade to be more of the same. People seemed doomed to reinvent the wheel!<\/p>\n","protected":false},"excerpt":{"rendered":"