As some of you may be aware, I’ve been working on a scheme for cataloguing my book collection for as long as I’ve known what a book catalogue is, which is somewhere on the order of a quarter century now. I’ve started numerous times and even managed to create something useful in some instances. However, my efforts have always been somewhat lacking for various reasons.
In the early days, the lack of capability of the computer systems I had at my disposal was a severe limiting factor. I employed some amusing tricks to get things working in a manner that would not limit me too much. Some of the tricks I employed were less than amusing.
Eventually, I discovered relational databases and thought that they might be the solution to the data storage problem. However, as I tinkered with them, I realized that my goals were fundamentally incompatible with the relational paradigm. Oh, it isn’t that the data cannot be expressed relationally so much as the data doesn’t naturally fit into a rigid schema which relational databases usually require. While a non-schematic data structure can be implemented in a relational database, the benefits of using such a database pretty much evaporate when one does so.
Finally, I discovered the NoSQL “movement” which came into its own in 2009. I spent some time reading about the various NoSQL schemes out there and stumbled across MongoDB which seems to fit the needs of my book catalogue perfectly. MongoDB does not enforce any sort of schema on objects stored in the database and it uses a relatively simple variation on JSON to store data. This makes it trivial to store random extra information about a book (or an author if need be) without having to resort to the somewhat complicated gymnastics a relational database requires.
I will concede that the MongoDB scheme is noticeably slower for many operations. However, most of the operations that are slow are either a result of my own relative ineptitude with MongoDB or they are operations that are not performed regularly. Even so, the flexibility offered by MongoDB is well worth a speed trade off. And we talking going from no noticeable time taken to perform a task to maybe a few seconds. This is hardly a great hardship.
So, those of you out there looking to solve problems which suffer from data that is not strictly regular are strongly encouraged to look into MongoDB and its cousins.