No in NoSQL Means No-torious
If there is one thing that makes backend systems a joy to develop and a mountain to overcome, it is, unsurprisingly, the knowledge of data and the choice of technology stack, the design of their interrelationships, the ability to shape and transform them, and the wit to implement and continuously improve them. But, after the honeymoon of initial development, when developers are free to shape code-wise the system as they see fit, comes the struggle of making sure that future updates will yield little to no breaking changes, especially with the data itself stored in the database of course.
One of the common nuisances, for some, with maintaining and using a database is the utmost care and consideration for existing data, albeit old. You see, the database schemas should be structured in a way that is similar and as close to perfection as possible.
In this context, let us say that the following traits describe perfection:
- Normalized data or no duplication
- Separation according to purpose, domain, or context
- And so on, which you have already tackled in your college database management courses.
Well, throw all of these out the window since we are using a non-relational database or NoSQL called MongoDB which gives developers the dilemma of making a very weird and off-putting decision to choose between the two computer science tradeoffs, performance vs. storage.
Do you want fast queries? Avoid lookups, which means embedding documents instead of references, which results in more storage being used.
Do you want no data duplication and easily contextualized data? Then suffer the slow queries.
Also, writing queries in JSON-similar syntax, with or without the aggregation pipeline, is so terrible. There is a reason—actually a ton of them—why Javascript is dreaded by a lot of good programmers.
INSANE!