There is a terrific database available called MongoDB, and I recommend you try it. Here’s a meandering explanation of why MongoDB is an excellent database system worthy of your attention.
Imagine you are putting together a database of academic classes such as Art, Math, and Geometry. You want to store a list of things students are required to buy and bring to class. For Art, it may be pencils, crayons, pastels, erasers. (This is just a thought experiment. I’m under no legal obligation to represent these supplies accurately.) For Geometry, they should have pencils, protractor, compass, and a ruler.
One way to do this in SQL is to create a table of class subjects, and then create a field/column that contains an indexed value pointing to a second table consisting of student supplies. When you want to find out what supplies the kids will need for Art class, you grab the supplies index field from the Art class row and use that to look up multiple rows in the supplies table.
The SQL approach is an overly complex way to handle data for this particular use case. A better way to store the data would be to allow each row (sometimes called a record) to have fields that contain multiple values. So, the Art row could have a field called “supplies” which holds multiple values, including “pencils”, “crayons”, “pastels” and “erasers”. This is called a multi-value field.
That's how MongoDB works. The Art document (a SQL row is a MongoDB document) could have a field called “supplies” which holds multiple values, including “pencils”, “crayons”, “pastels” and “erasers”.
My first exposure to this non-SQL approach was back when I wrote a review of Advanced Revelation for DOS back in the ‘80s.
Damn, I’m old.
Advanced Revelation was based on something called the “Pick operating system” and had multi-value fields. It also had a menu system that provided a way to do everything except what I wanted to do next. It drove me crazy. However much I didn't like it, I should add that I assigned the task of benchmarking Advanced Revelation to a colleague and she and loved it. She loved how it gave her access to the guts. “I can use a B-Tree here, and optimize the bilateral crankshaft duflabber there, and wheee!” No, thanks. I want products to decide those things for me.
Incidentally, the product lives on as OpenInsight10, although it looks like the last update to the web site was in 2018.
Regardless of how I felt about the usability of Advanced Revelation, I recognized the advantages of having multi-value fields for many use cases. So, when I discovered MongoDB has the same feature, that piqued my interest in the product.
Back to MongoDB
Multi-value fields is just one feature of MongoDB. What makes this feature special is how well it is implemented. What a SQL database calls a table row, MongoDB calls a document, specifically a BSON document. BSON is Binary JSON, so any contemporary programmer worth his or her salt will find this intuitive. You insert records into MongoDB as JSON documents. MongoDB stores the documents as BSON. If you want MongoDB to export it back, this is what you'd see when you export the data from MongoDB to plain JSON:
[{
"_id": {
"$oid": "64404a40f87296e4ad25ab04"
},
"topic": "Art",
"required": [
"Pencils",
"Crayon",
"Pastels"
]
},{
"_id": {
"$oid": "64404a8bf87296e4ad25ab05"
},
"topic": "Geometry",
"required": [
"Pencils",
"Protractor",
"Compass",
"Ruler"
]
}]
The above is considered a collection of two documents, a "table" in SQL. One reason MongoDB uses BSON instead of JSON for storage is that Binary JSON adds things like the type of value, something you don't see in JSON.
Multi-value fields aren’t simply convenient for use cases, they can make your data more durable. The fidelity of a transaction is described by the acronym ACID, that is, Atomicity, Consistency, Isolation, and Durability. Consider what you must go through to perform a transaction in SQL. SQL transactions, like a financial transaction, almost always occur between two or more tables. So, you must record the current state of the tables, lock the tables, perform the transaction, and then unlock the tables. If something goes wrong, you roll back the transaction and set the tables to their original values.
Databases like MongoDB make it less likely that you’ll need multiple tables to perform a transaction. This simplifies data reliability and durability across transactions. In many cases, you won't need to deal with journaling and rollback.
Even though MongoDB is considered a NoSQL database, that doesn’t mean it lacks some of the useful features of SQL. It supports the kind of operations you normally associate with SQL, such as queries that span multiple tables (in this case document collections).
Python programmers should adore MongoDB. It’s almost custom-made for Python. But there are libraries to make MongoDB work with a feces-load of other languages, too, like C, C#, Java, Javascript, PHP, and even the oddballs like Rust, Scala, Swift and TypeScript.
Now, I’ve pretty much limited my coverage here of the feature that caught my attention, but there’s so much more. Trust me when I say you’ll find it easy to jump in and start playing with MongoDB, again, especially if you’re familiar with Python.
Finally, if you don’t know where the subject title “Candygram for Mongo[DB]” comes from, rent a copy of Mel Brooks’ 1974 movie, Blazing Saddles.
Damn, I’m old.
Resources:
MongoDB: https://www.mongodb.com/
Documentation: https://www.mongodb.com/docs/develop-applications/
Drivers: https://www.mongodb.com/docs/drivers/
Revelation Software: https://www.revelation.com/index.php?option=com_content&view=category&id=28&Itemid=213
