C'est vrai, je suis d'accord, cependant tout dépend du besoin. Quand tu veux faire du CMS, de la vitrine, un site métier mais sans fortes contraintes relationnelles, ou juste quand tu es le commun du mortel, le choix entre un SGBD et une base NoSQL est parfois ambigu: les deux vont fournir les fonctionnalités nécessaires et suffisantes pour le besoin, et les deux vont écrire noir sur blanc dans leur documentation que c'est le bon outil pour implémenter ce besoin. Finalement, tout comme les SGBD, MongoDB est assez polyvalent lui aussi.
La seule différence sera dans la façon de l'utiliser, et souvent la bonne réponse reste le SGBD conventionnel un poil plus polyvalent. C'est juste une question d'échelle, si passer au NoSQL ne déverrouille pas une contrainte que tu aurais avec le SGBD classique (comme par exemple, le besoin de passer à l’échelle horizontalement, et encore que...), autant rester sur l'ennuyeux SGBD classique car c'est souvent un outil plus mature, plus stable, pour lequel on trouvera un meilleur support et plus de gens compétents pour travailler avec.
Je ne comprends pas trop les gens qui disent "j'étais avec X, oulala les galères, je suis passé sur Y (Y ayant rien à voir avec X),
C'est là que je ne suis pas d'accord. À l'époque, et c'était un choix de design logiciel assumé par MongoDB, une lecture et une écriture en même temps sur la collection influaient l'une sur l'autre, et des enregistrements pouvaient simplement ne pas être écrit, des mises à jour pouvaient être ignorées, et la lecture pouvait lire un même document deux fois, etc... C'était des comportements très grave, et impossibles à ignorer dans notre contexte, où on avait beaucoup de lectures et écritures concurrentes.
Maintenant ils semblent avoir implémenté correctement quelque chose qui ressemble enfin à des transactions, mais il leur a fallu du temps, plusieurs années même. Ça refroidit vraiment, c'est devenu pour nous un outil à fuir absolument. Trop de mauvaises surprises, et certains étaient même assumées par ses mainteneurs et marqués comme étant "par design".
Ma machine à laver n'est pas meilleure que mon vélo.
Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données. Il y a une intersection entre les deux espaces fonctionnels fournis par ces deux outils. Je pourrais dire la même chose avec Cassandra et MSSQL, ou encore bien d'autres bases de données.
tu entends "sauf ma majeure partie des fonctions relationnelles"
Non pas forcément, PostgreSQL va bien au delà, il convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin), pour faire du publish/subscribe (event/notify), pour implémenter de la recherche fulltext, et ses capacités vont encore bien au delà (et sans parler des extensions). MongoDB s'est amélioré avec le temps, je dis pas, seulement, vu son âge finalement peu avancé comparés à beaucoup d'autres bases de données, je lui fais encore pas confiance.
[^] # Re: Scylla/MongoDB
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 6.
C'est vrai, je suis d'accord, cependant tout dépend du besoin. Quand tu veux faire du CMS, de la vitrine, un site métier mais sans fortes contraintes relationnelles, ou juste quand tu es le commun du mortel, le choix entre un SGBD et une base NoSQL est parfois ambigu: les deux vont fournir les fonctionnalités nécessaires et suffisantes pour le besoin, et les deux vont écrire noir sur blanc dans leur documentation que c'est le bon outil pour implémenter ce besoin. Finalement, tout comme les SGBD, MongoDB est assez polyvalent lui aussi.
La seule différence sera dans la façon de l'utiliser, et souvent la bonne réponse reste le SGBD conventionnel un poil plus polyvalent. C'est juste une question d'échelle, si passer au NoSQL ne déverrouille pas une contrainte que tu aurais avec le SGBD classique (comme par exemple, le besoin de passer à l’échelle horizontalement, et encore que...), autant rester sur l'ennuyeux SGBD classique car c'est souvent un outil plus mature, plus stable, pour lequel on trouvera un meilleur support et plus de gens compétents pour travailler avec.
C'est là que je ne suis pas d'accord. À l'époque, et c'était un choix de design logiciel assumé par MongoDB, une lecture et une écriture en même temps sur la collection influaient l'une sur l'autre, et des enregistrements pouvaient simplement ne pas être écrit, des mises à jour pouvaient être ignorées, et la lecture pouvait lire un même document deux fois, etc... C'était des comportements très grave, et impossibles à ignorer dans notre contexte, où on avait beaucoup de lectures et écritures concurrentes.
Maintenant ils semblent avoir implémenté correctement quelque chose qui ressemble enfin à des transactions, mais il leur a fallu du temps, plusieurs années même. Ça refroidit vraiment, c'est devenu pour nous un outil à fuir absolument. Trop de mauvaises surprises, et certains étaient même assumées par ses mainteneurs et marqués comme étant "par design".
Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données. Il y a une intersection entre les deux espaces fonctionnels fournis par ces deux outils. Je pourrais dire la même chose avec Cassandra et MSSQL, ou encore bien d'autres bases de données.
Non pas forcément, PostgreSQL va bien au delà, il convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin), pour faire du publish/subscribe (event/notify), pour implémenter de la recherche fulltext, et ses capacités vont encore bien au delà (et sans parler des extensions). MongoDB s'est amélioré avec le temps, je dis pas, seulement, vu son âge finalement peu avancé comparés à beaucoup d'autres bases de données, je lui fais encore pas confiance.