Why is that you rarely (meaning never) stumble across a tutorial for <–insert js framework here–> that makes use of one of the most widely used databases available? It’s MERN (Mongo, Express, React, Node) this or MEAN (Mongo, Express, Angular, Node) that. Has everyone unanimously given SQL the finger in favor of using Mongo?
I use SQL every day at work and have come to really enjoy it. Perhaps not as much as after embarking on a project making extensive use of Mongo. What’s the difference you ask? Mongo is a key-value store that stores data as JSON, has its own query language and is lightning fast at retrieving info. Mongo, like Firebase, another key-value store (that I highly recommend for start-up/weekend/light data projects), are NOSQL databases, meaning the data is not relational, or table-based.
SQL on the other hand is, well, a SQL database that holds data that is relational, or tabluar. If you’re not familiar with SQL, imagine Excel for coders. That’s really what it equates to. SQL is great for storing relational information in tables, like a table with users for your app, a table for their passwords, and another for messages they’ve posted. All three of these tables are related by the user name or id and the data types are unlikely to change. SQL makes use of data types, so you once you’ve defined a column and datatype, it’s set in stone, which has its pros and cons. PRO: your data maintains integrity and you can expect certain datatypes being returned. CON: In today’s JS-centric world, we’re used to receiving JSON and if you’re unsure of how your data will be structured or the types you will allow, SQL may pigeon-hole you too early in the game.
Rather than thoughtfully choosing a database based on the type of application I was building, I decided to be like the cool kids and jumped headfirst into Mongo although my data would likely have been easier to wrangle in a SQL type structure… oops. Being a SQL guy, I incorporated Mongoose (a library for Mongo) to create a schema for my json data that allows you to define data types and things like length and whether a field is required or not. Basically, I was trying to SQL-ify my Mongo instance.
Things were going great at first and I really enjoyed Mongo’s query language and the fact they have their own query editor (Robo 3T) which made designing my queries all the easier. Things began getting hairy however, when I wanted to do things like join documents like you would with relational tables. My queries were getting more complicated to try to force some relation between documents in an inherently non-relational database. You see, in a SQL world, I would have created a users table and a messages table, with the messages table storing messages from a user, the user id, the time created and who they were sent to, then easily joined that table to my user table. Easy fucking breezy. With Mongo, I created a users document and a messages document but joining these documents and maintaining their order has proven hairier than I anticipated.
I’m glad I joined the cult of Mongo however, as I’ve really come to enjoy its flexibility; decided you don’t want to include user id anymore? Fuck it, just don’t use that property anymore in your new entries, meanwhile, try dropping a column in SQL that another table depends on, or just changing up a datatype for a column or storing different datatypes in the same column (you just forget about that you sick bastard!).
I’m gonna see this MERN project through and get a nice break from my day to day SQL queries but I think I may have to pioneer the SERN/SEAN stack next.
If you’re thinking of using Mongo for your next project, I recommend using Mlab which offers a free tier that hosts your mongo database and Mongoose if you want to add some rules for your datatypes and schema.