> If you know exactly what you want, sure SQL is the way to go. I've been doing similar aggregations with MongoDB, simply because when I start a project where

> If you know exactly what you want, sure SQL is the way to go. I've been doing similar aggregations with MongoDB, simply because when I start a project where I quickly want to store data and then a week later check what I can do with it, it's a tool which is trivial to use. I don't need to think about so many factors like where and how to store the data. I use MongoDB for its flexibility (schemaless), compared to SQL. But I also use SQL mostly because of the power relations have, yet I use it only for storing stuff where it's clear how the data will look for forever, and what (mostly simple) queries I need to perform. I've read your comment as if it was suggesting that these kind of articles are not good, yet for me it was a nice overview of some interesting stuff that can be done with SQL. I don't chase articles on SQL, so I don't get many to read, but this one is among the best I've read. To get back to the quote: How will I know if SQL can do what I want, if I don't read these kind of articles?