J'utilise des bases de données NoSQL depuis un certain temps maintenant, et voici ma contribution au sujet:
Un excellent cas d'utilisation d'une base de données NoSQL est une application de génération de statistiques et / ou de rapports , en particulier lorsque les données sont fournies à partir d'une source tierce.
Dans une situation comme celle-là, une base de données NoSQL peut être un excellent choix
Prenons, par exemple, MongoDB :
Une fois que vous avez vos données en JSON (elles peuvent provenir d'une API tierce ou être exportées à partir d'une application sql) dans MongoDB, il est assez simple d'importer et de mettre à jour les données JSON dans la base de données; par exemple en utilisant l' mongoimportutilitaire de ligne de commande
À ce stade, il est très simple de créer des requêtes dynamiques avec filtrage et regroupement, qui correspondent bien à ce type d'application.
Par exemple, en utilisant le framework d'agrégation :
$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 );
Je voudrais souligner la facilité avec laquelle nous pouvons ajouter / supprimer des filtres de manière dynamique utilisant des structures de données php et en évitant la concaténation de chaînes fastidieuse pour construire nos requêtes. Avec cette approche, ajouter / supprimer des filtres de manière dynamique est aussi simple que d'ajouter / supprimer des éléments d'un tableau
Un autre grand avantage vient du fait qu'une solution comme celle-ci est susceptible d'être plus rapide que l'utilisation d'une base de données relationnelle , où nous devons faire des jointures avec différentes tables pour obtenir toutes les données dont nous avons besoin.
De plus, ce cas d'utilisation est optimal car évite toutes les principales limites d'une base de données NoSQL:
Manque de transactions: l'application n'effectue pas d'écritures mais uniquement des lectures, nous n'avons donc pas du tout besoin de transactions
Manque de jointures entre les tables: nous n'avons pas besoin de jointures, car nous pouvons utiliser la redondance pour stocker nos données dénormalisées dans les collections. Comme nous lisons uniquement des données, nous n'avons pas à nous soucier de la synchronisation des données dénormalisées entre les mises à jour.
De cette façon, nous pouvons nous concentrer sur le stockage des données avec redondance d'une manière qui correspond bien à nos requêtes , qui se concentreront sur des collections uniques.
J'écris juste ceci parce que si j'avais lu quelque chose comme ça il y a quelques temps, cela m'aurait fait gagner du temps pour faire des recherches
J'espère que cela sera utile à quelqu'un