Pour votre cas particulier, MongoDB semble être un bon choix, mais il existe de nombreux scénarios (probablement la plupart d'entre eux) où ce ne serait pas le meilleur choix.
MongoDB est plus adapté dans les scénarios qui nécessitent de lire / écrire beaucoup de données, sans trop mettre l'accent sur la sécurité des transactions (si certaines données sont occasionnellement perdues lors d'une panne de serveur, ce n'est pas un problème), attendez-vous à une grande échelle et ne le faites pas '' t vraiment un schéma stable.
MongoDB n'est pas adapté aux scénarios qui nécessitent:
- Fortes garanties ACID: MongoDB permet de stocker des données en double, des lectures incohérentes et même une perte de données. Ces choses sont très bien dans certaines applications, mais pas dans la plupart.
- Transactions multi-objets: MongoDB prend en charge les transactions ACID, mais uniquement pour un seul objet / document. Cela ne suffira pas pour les opérations plus complexes comme les virements bancaires, la réservation, etc.
- BI traditionnelle: il existe de nombreux outils de BI qui ne fonctionnent bien qu'avec le SQL traditionnel.
- SQL: MongoDB a un langage de requête très spécifique, alors que SQL est très bien connu par beaucoup de gens (peut être un aspect important à considérer), peut faire beaucoup de choses complexes (alors qu'avec MongoDB vous auriez du mal à effectuer un simple rejoindre) et est transférable à travers de nombreuses implémentations.
MongoDB est plus rapide et vous permettra d'augmenter les performances du système en éliminant beaucoup de choses que le SGBDR applique par défaut, comme les contrôles d'intégrité (notez que vous pouvez également modifier le SGBDR à de telles fins, de toute façon), mais la vérité est, dans la plupart des scénarios, ce n'est tout simplement pas nécessaire. De plus, le compromis est la fiabilité et la flexibilité (vous aurez des problèmes si, plus tard, vous décidez que vous devez effectuer des opérations plus complexes avec les données existantes).
Tout dépend des besoins de l'application que vous créez. Est-ce la vitesse et la disponibilité, ou la sécurité, la fiabilité et la flexibilité. Vous devez savoir où dans vos données (et dans les connexions de vos données) se trouve plus de valeur. Si vous ne le savez pas encore, il est probablement préférable de choisir quelque chose qui ne vous peindra pas dans le futur, et vous permettra d'ajouter les fonctionnalités et d'effectuer les opérations dont votre application a besoin.