I have been using NoSQL DBs for a while now, and this is my contribute to the topic:
A great use case for a NoSQL database is an application for statistics and / or reports generation,
expecially when data is provided from a third party source.
In a situation like that a NoSQL database can be a great choice
Let's consider, for example, MongoDB:
Once you have your data in JSON, ( it could come from a third party API, or be exported from an sql-application) in MongoDB is pretty strightforward to import
and update the JSON data in the database; for example using the command-line mongoimport utility
At this point is very simple to build dynamic queries with filtering and grouping, that well fit with this kind of application.
For example, using the Aggregation Framework:
$pipeline = [];
//filter by date
$pipeline[] = [ '$match' => [ 'created_at' => [ '$gte' => $starDate, '$lte' => $endDate ] ] ];
//if we want to filter by a specific field, we add the filter to the pipeline array
if( $filters->isFilterByField() )
$pipeline[] = [ '$match' => [ 'field' => $fieldValue ] ];
//group the results by date and get the count
$pipeline[] = [ '$group' => [ '_id' => '$created_at', 'num_elements' => [ '$sum' => 1 ] ] ];
return $collection->aggretate( $pipeline );
I'd like to point up the easiness with which we can dinamically add/remove filters using php data structures and avoiding tedious
string concatenation to build up our queries. With this approach adding/removing filters dinamycally is as easy as adding / removing
elements from an array
Another great benefit comes from the fact that a solution like this is likely to be faster than using a relational database,
where we have to make joins with different tables to get all the data we need
Besides, this use case is optimal because avoids all the principal limits of a NoSQL database:
Lack of transactions: The application doesn't perform writes but only reads, so we don't need transactions at all
Lack of joins between tables: We don't need joins, as we can use redundancy to store our denormalized data in the collections.
As we only read data, we don't need to be worried about synchronizing denormalized data among updates.
This way we can focus on storing the data with redundancy in a manner that well fits to our queries, that will be focus on single collections.
I'm just writing this because had i read something like that some times ago, it would have been saved me some time to make researches
Hope it will be useful to someone
