IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Au revoir MongoDB » : le témoignage d'un développeur qui a changé MongoDB pour PostgreSQL
Il révèle aussi les inconvénients et les limites du SGBD NoSQL

Le , par Bruno

42PARTAGES

17  0 
Dans un billet de blog, Stuart Spence raconte son parcours avec MongoDB, une base de données NoSQL qui permet de stocker des documents au format JSON. Il explique qu’il a commencé à utiliser MongoDB en 2017, séduit par sa simplicité, sa flexibilité et sa performance. Il décrit les différents projets sur lesquels il a utilisé MongoDB, en soulignant les avantages qu’il en a tirés, comme la facilité de développement, la scalabilité et la richesse des fonctionnalités.

Cependant, il révèle aussi les inconvénients et les limites de MongoDB, qu’il a découverts au fil du temps. Il cite notamment les problèmes de fiabilité, de sécurité, de consistance et de complexité des requêtes. Il explique que ces problèmes l’ont amené à remettre en question son choix de base de données, et à envisager une alternative plus adaptée à ses besoins.


Il présente alors PostgreSQL, une base de données relationnelle qui offre des garanties de qualité, de robustesse et de standardisation. Il explique pourquoi il a choisi PostgreSQL comme nouvelle base de données, en mettant en avant ses avantages par rapport à MongoDB, comme la maturité, la stabilité, la compatibilité et la diversité des extensions.

MongoDB est un système de gestion de base de données orienté documents, répartissable sur un nombre quelconque d'ordinateurs et ne nécessitant pas de schéma prédéfini des données. Il permet de manipuler des objets structurés au format BSON (JSON binaire), sans schéma prédéterminé. Il est écrit en C++. Le serveur et les outils sont distribués sous licence SSPL.

En octobre 2018, la base de données MongoDB est publiée sous SSPL. La plupart des utilisateurs de MongoDB n'ont pas besoin des nombreuses fonctionnalités avancées offertes par MongoDB, mais ils ont besoin d'une solution de base de données open source.

En 2019, MongoDB annonce un chiffre d’affaires de 99,4 millions de dollars, en hausse de 67 %, sur le 2e trimestre de son exercice 2020. L’éditeur de la base de données revendique 15 000 clients dans plus de 100 pays, en incluant ceux qu’il a acquis avec les rachats d’ObjectLabs et de la base de données mobile Realm (ex-Tightdb).

Alors que la perte d’exploitation a été réduite de moitié pour atteindre 14,8 millions de dollars, les revenus du deuxième trimestre ont augmenté de 67 %, les produits tirés des abonnements se sont élevés à 94,2 millions USD, en hausse de 71 % par rapport à 25,2 millions USD, tandis que ceux des services professionnels ont atteint 5,2 millions USD, en hausse de 15 % par rapport à l'année précédente.

En 2021, MongoDB annonce la disponibilité de Realm Sync, un dispositif de synchronisation des données dans le cloud. « Afin d’appuyer notre stratégie informatique de pointe, nous avons commencé à étendre l’utilisation des technologies d’automatisation dans nos centres de distribution. Nous évaluons l’opportunité d’utiliser Realm et Realm Sync dans les cas d’utilisation d’envoi de colis entrants et sortants », avait déclaré James Fairweather, Directeur de l’innovation chez Pitney Bowes.

« Par exemple, nous envisageons de créer une application sur Realm pour nos collaborateurs de première ligne qui permettrait de scanner un colis pour synchroniser automatiquement les données avec MongoDB Atlas. Cela permettrait d’assurer la cohérence des rapports et de garder la logistique à jour tout au long de l’expédition ».

Les problèmes de Mongo

« Le choix de Mongo est peut-être mon plus grand regret technique dans un projet logiciel. J'ai lu de nombreux guides. J'ai essayé et mesuré de nombreux changements de configuration. Mon code Python-Flask a fait des pirouettes pour Mongo », déclare Spence. Voici, ci-dessous, quelques faiblesses évoquées par Spence :
  • erreurs de connexion fréquentes (ServerSelectionTimeoutError, OperationFailure, AutoReconnect) ;
  • utilisation erratique de la mémoire vive dépassant de loin ce que le trafic devrait exiger ;
  • parfois le service refuse de redémarrer (systemctl restart/start) ;
  • des procédures de mise à jour difficiles (après apt dist-upgrade) ;
  • procédures de migration difficiles pour un nouveau moteur de stockage (WiredTiger) ;
  • pas de support officiel pour le dernier Ubuntu LTS des mois après sa sortie ;
  • documentation peu claire sur "mongo.com" à propos des requêtes ;
  • mauvaise documentation sur pymongo.

Enfin, Spence indique que l'écriture des insertions et des mises à jour en JSON est compliquée. « Ce qui devrait être une opération assez simple comme : "Incrémenter atomiquement cette valeur imbriquée, ou insérer si la valeur n'est pas là" était tout simplement un désastre », déclare-t-il. Par exemple, incrémenter "api" de un ou insérer "api":1 si nécessaire :

Code : Sélectionner tout
1
2
3
4
5
6
{"turtle":123,
 "visit_count":{"web":2,
                "api":8}}
 
{"turtle":123,
 "visit_count":{"web":3}}
Les distributions Debian, Red Hat Enterprise Linux et Fedora Linux ont par la suite abandonné MongoDB, invoquant des inquiétudes concernant la SSPL. Amazon a publié un service compatible, mais propriétaire nommé DocumentDB, et il est apparu que la SSPL n'a pas réussi à augmenter les revenus du cloud pour MongoDB.

Migration des données de MongoDB vers PostgreSQL

Dans son billet de blog, Stuart Spence détaille le processus qu’il a suivi pour migrer ses données de MongoDB vers PostgreSQL, en insistant sur les défis et les solutions qu’il a rencontrés. Il décrit les outils qu’il a utilisés pour effectuer la conversion des données, la validation des résultats et le déploiement des changements. Il donne aussi des conseils pour optimiser les performances, la sécurité et la maintenance de PostgreSQL.

« PostgreSQL a été un choix facile. J'ai failli le choisir en 2019, c'est un logiciel libre, mature et très populaire. Je n'ai pas besoin de ses fonctionnalités sophistiquées, mais c'est bien qu'elles existent. Grâce à une bonne planification, ma classe Python DatabaseManager sépare ma logique métier des spécificités de la base de données. Il m'a donc suffi de remplacer Mongo par PostgreSQL dans toutes ces fonctions », précise Spence.

« Une chose qui est un peu choquante est que j'ai écrit une fonctionnalité JSON de type Mongo au-dessus de PostgreSQL et, pour autant que je puisse en juger, elle fonctionne beaucoup plus rapidement », ajoute-t-il. Par exemple, une des fonctions Python retourne les résultats SQL sous forme de liste de dictionnaires basés sur les noms de colonnes de la table :

Code : Sélectionner tout
1
2
3
4
SELECT a, b, c FROM table1 ;
 
[{"a":2,"b":3,"c":4},
 {"a":11,"b":44,"c":66}]
Il affirme qu’il ne regrette pas son passage à PostgreSQL, qu’il trouve plus fiable, plus performant et plus simple à utiliser que MongoDB. Il reconnaît toutefois que MongoDB reste un bon choix pour certains cas d’usage, comme les applications qui nécessitent une grande flexibilité ou une grande scalabilité.

Si l'avis de Stuart Spence peut paraître trop sévère, il nous montre tout de même qu’il n’existe pas de base de données idéale, mais que chaque base de données a ses forces et ses faiblesses, en fonction du contexte et des besoins du projet. La vision négative de Spence au sujet de MongoDB reste questionnable. En effet, le choix d’une base de données peut aussi être un choix stratégique, qui peut avoir un impact important sur la qualité, la performance et la sécurité de nos applications. Pour certains analystes d'ailleurs, MongoDB est une base de données innovante, qui offre des possibilités de stockage et de manipulation des données très intéressantes, notamment pour les applications web modernes.

Source : Stuart Spence's blog post

Et vous ?

Quel est votre avis sur le sujet ?

Quel SGBD utilisez-vous ? Qu'est-ce qui motive votre choix ?

Quels sont les défis ou les difficultés que vous avez rencontrés avec votre SGBD ?

Quels sont les types de projets pour lesquels vous recommanderiez MongoDB ou PostgreSQL ?

Voir aussi :

MongoDB Inc. annonce un chiffre d'affaires de 99,4 millions USD au deuxième trimestre de son exercice fiscal 2020, une hausse de 67 % largement tirée par la part des abonnements en hausse de 71 %

MongoDB annonce la disponibilité de Realm Sync, un dispositif de synchronisation des données dans le cloud, pour accélérer le développement d'applications mobiles essentielles

MangoDB : une véritable alternative Open Source à MongoDB, un proxy open source, qui convertit les requêtes du protocole filaire de MongoDB en SQL

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Seb_de_lille
Membre habitué https://www.developpez.com
Le 05/07/2023 à 10:59
Citation Envoyé par maxtal Voir le message
J'ai eu le déplaisir de bosser avec MongoDB pendant un stage, après 2 autres développeurs qui avaient chacun sa conception, et c'était juste l'enfer, des doublons dans tous les sens, aucune cohérence dans les structures...
Maintenant quand je vois ça sur une mission je refuse directement, on a assez de problèmes en bossant avec des technos fiables pour s'en rajouter avec des technos souvent pas maitrisées ou mal utilisées.

PostgreSQL & MySQL ftw
Comme cela était dit dans l'article, MongoDB n'est pas la solution à tout. De mon expérience personnelle, les plus gros soucis que j'ai rencontré sont souvent dus à une mauvaise utilisation. Trop souvent, j'ai vu les développeurs partir sur mongo "parce qu'il n'y a rien à faire".
8  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 07/07/2023 à 12:06
Citation Envoyé par shenron666 Voir le message
... sachant pas que le "no" ne veut pas dire "no" mais "not only" ?...
Pas tout à fait... Au début de l'épopée du NO SQL, c'était bien le NO revendicatif du "on ne veut plus du SQL"...

Cette tendance à dégommer les SGBD Relationnel a eut lieu de tous temps. Au début du relationnels en 1985 Franck Edgar Codd a été obligé de publier des articles notamment
  • "is your DBSM realy relational ?"
  • "does your DBMS run by the rules ?"

Dans le magazine "Computerworld"
https://www.computerworld.com/articl...-12-rules.html
Pourquoi ? Parce que déjà, les tenants des anciens modèles de base de données non relationnels, john Culliname en tête, voulait dézinguer les SGBD Relationnels qu'il voyait concurrencer ses produits... Peine perdu, les anciens modèle hiérarchique etc. Ont aujourd'hui preque tous disparus.

Au cours des décennies, de nombreuses autres modes ont essayé de pourrir les SGBD Relationnels pour prendre des parts du gateau...

Fin 80 début 90 ce furent les SGBD Objets (GemStone, O2, Poet...) c'est sur le relationnel était mort, vive les SGBDO ! Hélas ces dinosaures avant l'âge n'ont pas supportés la puisance du relationnel
Fin 90 début 2000 les serveurs d'objets devaient remplacer les SGBDR...

Début 2000 les grands acteurs d'Internet voyait d'un mauvais œil les SGBD Relationnels, car il auraient dû acheter des licences. C'est pourquoi, de concert, les "fesse de bouc", "tweet merde" et autres "amazunic" se sont ligués (GAFA) pour combattre les SGBDR en indiquant que c'était une technologie vieillotte et has been et qu'ils allaient faire mieux...
Pour essayer d'assoir leur affirmations mensongères, ces acteurs n'ont pas hésité à introduire une "fake news" en prenant pour pivot le théorème CAP de Brewer qui indique qu'un SGBD, quel qu'il soit, ne peut assurer de façon synchrone les trois fonctionnalités suivantes :
  • C : CONSISTANCY, c'est à dire la cohérence des données assurée par les transactions dans les SGBD Relationnels
  • A : AVAILABIBILITY, c'est à dire la disponibilité des système, via un système de redondance prenant automatiquement le ,relais en cas de défaillance d'un serveur (maillage du système par une batterie de serveur appelés noeud)
  • P : PARTITIONNING, c'est à dire le partitionnement des informations, un serveur pouvant avoir une partie de l'information, d'autres nœuds assurant le stockage des autres partitions.

https://ieeexplore.ieee.org/abstract/document/6133253
Or les tenants du NoSQL ont sciemment omis le mot SYNCHRONE, faisant croire qu'aucun SGBD Relationnel n'était capable d'assurer les trois fonctionnalités (seuls les imbéciles buvant ces paroles hypocrites on crus de tels mensonges.). Déjà à l'époque IBM Db2, Oracle Database et SQL Server avaint des outils de partitionnement des nœuds, haute disponibilité et bien entendu le transactionnement. Par exemple dès la version 7 de SQL Server il y avait le partitionnement des instances via les bases de données partitionnées fédérées et le clustering pour la haute disponibilité. mais il a fallu attendre la version 2005 pour qu'une haute résilience plus efficace voit le jour avec le mirroring puis en 2012 avec alwaysOn avec plusieurs nœuds...

C'est à ce moment que le terme des aficionados du "No SQL" voulait réellement dire "SQL, va te faire foutre..."

"
The acronym NoSQL was first used in 1998 by Carlo Strozzi [...]. The term NoSQL can mean either “No SQL systems” or the more commonly accepted translation of “Not only SQL,” to emphasize the fact some systems might support SQL-like query languages.
"
https://www.dataversity.net/a-brief-...nal-databases/

Cependant les choses n'allèrent pas aussi bien dans les SGBD NoSQL que dans le SQL. L'absence de gestion des transaction fit perdre beaucoup d'argent à Amazon dont certaines comma,ndes disparaissent mystérieusement comme certains paiement !
Amazon fut donc le premier à rétablir la gestion des transaction dans sa base NoSQL...
D'autres envisagèrent un langage plus moderne que le SQL, suggérant que le fait de commencer par la clause SELECT d'une requête est une aberration, puisque c'est la partie qui propose les informations a renvoyer et devrait donc bien figurer en toute logique à la fin de la structure syntaxique du SELECT et non au début... On vit donc arriver un langage don,t la syntaxe de la commande d'extraction des données était :
Code : Sélectionner tout
1
2
3
4
5
6
FROM ...
WHERE ...
GROUP BY ...
HAVING ...
RETURNING ... --> l'équivalent de la clause SELECT
ORDER  BY...
le problème étant que cela ressemblait à 99% du SQL traditionnel et que de décaler une roue déjà inventée était une absurdité !

D'autres encore, commençait à comprendre que les milliers d'années hommes passés en R&D dans les SGBD Relationnels leur conféraient une avance technologie importante et incontestable tout en offrant de plus en plus de service (SIG, séries temporelles, historisation automatique, grid computing...). or la R&D coute cher et les éditeurs des grands SGBDR ont quelques longueurs d'avance... Dans les faits ce sont toujours et de très loin, les SGBD les plus utilisés !



https://dl.acm.org/doi/abs/10.1145/2452376.2452378

C'est à ce moment que le "No SQL" revendicatif du "que les SGBD Relationnels dégagent et qu'on en finisse" c'est transformé en un plus policé "Not Only SQL".... !

Il est a noter que depuis quelques années, le SQL revient en force dans l'univers du NoSQL sous le nom de New SQL ! Ayant enfin compris que les SGBD Relationnels seraient indétrônables, les GAFA se tournent maintenant vers le "New SQL" prétendant faire mieux que leurs ainés. Un seul exemple, Google Big Query

https://www.geeksforgeeks.org/sql-vs-no-sql-vs-new-sql/

Bref on rigole bien sur les mensonges des GAFA

Bilan final, quelques marchés de niche ont été inventé par les NoSQLeurs comme les bases de graphes, les bases in memory, les tables verticales, les document DB, le XML, le JSON... etc. Mais il y a belle lurette que tout cela a été intégré dans les SGBDR des grands éditeurs. Soit sous forme de module payant (Oracle) soit intégré dans tous les versions, y compris Express dans SQL Server !

Pour PostGreSQL bien qu'il intègre pas mal le JSON, il est défaillant sur le XML et n'a ni les index verticaux, ni le "in memory", ni le DATA LINK pour les documents électronique (ni la recherche sémantique...) ni les tables de graphe...
Mais visiblement les développeurs en ont enfin prix conscience et commence à envisager du sérieux, notamment en commençant à améliorer le moteur pour faire du parallélisme et du cache de haut niveau... Mais y'a un sacré gap avec les SGBD Relationnels d'entreprise comme DB2, Oracle ou SQL Server

A +
8  0 
Avatar de maxtal
Membre actif https://www.developpez.com
Le 05/07/2023 à 9:27
J'ai eu le déplaisir de bosser avec MongoDB pendant un stage, après 2 autres développeurs qui avaient chacun sa conception, et c'était juste l'enfer, des doublons dans tous les sens, aucune cohérence dans les structures...
Maintenant quand je vois ça sur une mission je refuse directement, on a assez de problèmes en bossant avec des technos fiables pour s'en rajouter avec des technos souvent pas maitrisées ou mal utilisées.

PostgreSQL & MySQL ftw
8  1 
Avatar de chris_FR
Membre régulier https://www.developpez.com
Le 05/07/2023 à 11:32
Quand on a trouvé un bon marteau ... tout les problèmes ressemblent à des clous

Le NoSQL comme les autres technos possèdent des avantages ET des inconvénients

La ou les bases relationnelles imposaient de réfléchir pour structurer les données (et encore ...), le NoSQL n'imposait plus rien NoStructure, Génial yapukacodé

eh ben non, il faut réfléchir ... et structurer les données sinon c'est vite le bordel ... et ce quelque soit l'outil (même chatGPT )
9  2 
Avatar de xbrossard
Membre régulier https://www.developpez.com
Le 05/07/2023 à 11:16
Citation Envoyé par Seb_de_lille Voir le message
Comme cela était dit dans l'article, MongoDB n'est pas la solution à tout. De mon expérience personnelle, les plus gros soucis que j'ai rencontré sont souvent dus à une mauvaise utilisation. Trop souvent, j'ai vu les développeurs partir sur mongo "parce qu'il n'y a rien à faire".
ah oui, ça je connaît:"Le développement Agile n'est pas la solution à tout. De mon expérience personnelle, les plus gros soucis que j'ai rencontré sont souvent dus à une mauvaise utilisation. Trop souvent, j'ai vu les développeurs partir sur Agile "parce qu'il n'y a rien à faire"

ou encore: "Le développement en Cascade n'est pas la solution à tout. De mon expérience personnelle, les plus gros soucis que j'ai rencontré sont souvent dus à une mauvaise utilisation. Trop souvent, j'ai vu les développeurs partir sur le modèle en Cascade "parce qu'il n'y a rien à faire"

bref comme d'habitude, c'est parce que les développeurs sont des branques que nos produits ne sont par reconnus. Mais à l'inverse, on se rend compte que quand on a des gens compétents, très souvent, quelque soit les outils/méthodes utilisés, ça marche!
6  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 05/07/2023 à 15:09
Citation Envoyé par franck971 Voir le message
Le post de ce développeur démontre un grand manque de maturité dans ses choix techniques.
Les outils no-sql, ne devraient pas etre intégrés pour remplacer les bases de données relationnelles.
Celles-ci ont des qualités irremplaçables en terme de normalisation, de sécurité et d'intégrité des données.
Tout à fait mais en même temps que faire si MongoDB est un choix imposé par la direction ? ou par le chef de projet ?
Pire encore, le plus gros de ceux qui sortent des formations privées, et voir des formations en général ont un niveau en base de données et en SQL quasi nul.
Le plus gros de ceux qui sortent des formations privées de développeur web ont bien un petit verni sur le front end qui pourrais faire illusion, mais pour ce qui est du back end c'est généralement clairement quasi nul, surtout sur les SGBD et SQL.
Même sur des sortants de Master Génie logiciel et MIAGE, qui proposent pourtant en théorie un vrai module de formation sur les SGBD et SQL, c'est à se demander si en vrai seulement un étudiant sortant sur 5 environ comprends quelque chose aux bases de données et à SQL.

Bref cet article est très intéressant car il pose le problème général du choix de NoSQL versus SQL et que choisir dans tous les cas NoSQL "parce que ça serait plus simple" est clairement une grosse erreur.
C'est justement aussi très intéressant de pouvoir lire la discussion qui s'en suit avec les expériences des professionnels

En conclusion je réitère l'avis selon lequel il est rare de tomber sur un informaticien doué en bases de données et en SQL et que quand on en trouve un bon on a intérêt à le chouchouter pour le garder
6  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 05/07/2023 à 15:13
Citation Envoyé par drcd Voir le message
Moi je fais le contraire

Comme le dit Seb_de_lille, les problemes avec Mongo resultent souvent d'une mauvaise utilisation. De mon point de vue, il ne faut pas raisonner de la meme manière qu'en SQL avec une base orienté documents.

Je peux également citer un contre exemple à notre ami Stuart. Le projet,dans lequel j'ai récupéré le lead, utilisait justement Postgres et stockait des données sous forme de json. Mais la manière dont ca avait été fait, faisait qu'au final on avait à la fois les incovénients des bases SQL et les inconvénients des bases document sans avoir le moindre avantage de l'une d'entre elle. .
Effectivement c'est un bon contre exemple.... Que faut-il prendre pour aller cherche un paquet de clope au coin de la rue ?
  • Une fusée transcontinental
  • Un jet
  • Un hélicoptère
  • Un camion
  • Une voiture
  • Un bateau
  • un vélo
  • une paire de baskets


Dans ton cas de figure le CDP choisit un tracteur pour aller chercher son paquet de clope... Prendra t-il une paire de baskets pour labourer son champ ?

Moi j'ai souvent vu le contraire... Un grand énergéticien dont je ne citerait pas le nom a eu la bonne idée de pendre MongoDB pour la facturation en remplacement d'une base de données relationnelles... Bilan des opérations, 2 mois de facturation foutu en l'air, incapacité à générer plus de 10000 factures par jours... etc. Au final retour en arrière chez un prestataire en edition

A +
5  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 06/07/2023 à 9:19
Citation Envoyé par drcd Voir le message
Contre exemple d'un des 3 grand opérateurs telecom chez qui j'ai bossé près de 10 ans. MongoDB etait utilisé pour la facturation et quand on parle d'opérateur telecom (j'imagine que c'est la meme chose pour les fournisseurs d'energie), on parle de plusieurs millions de clients, donc plusieurs millions de factures à sortir chaque mois, et bien aucun souci.

Ca illustre bien tous les échanges que nous avons ici
Mais cela n'a pas d'intérêt d'utiliser un SGBD fait pour du semi structuré voir du non structuré pour des objets qui sont hyper structurés comme une facture. Je ne crois pas qu'il y ait un objets dans le domaine des activités de l'entreprise qui soit aussi structuré qu'une facture dont le contenu est encadré par une législation très stricte... Alors oui, c'est possible, mais à quel coût comparativement à au coût pour un traitement équivalent en SGBD R...

Personnellement j'ai travaillé avec une entreprise européenne spécialisée dans la gestion des opérateurs téléphoniques et dont la facturation est d'un volume équivalent à cette de FT (devenu orange...). Constatant qu'ils avaient des difficultés avec du SQL Server ils avaient entrepris de refaire la chaine de facturation en NoSQL... (mongoDB et autres). Problème, dans le NoSQL la déduplication est quelques chose de très difficile, hors le système pouvait recevoir des tickets de téléphonie de différentes sources avec quelques doublons... A la fin, ils ont dû remettre les données dans un SGBD Relationnel pour cette phase finale !!! Bilan des opérations un traitement plus long !!!

A +
5  0 
Avatar de drcd
Membre averti https://www.developpez.com
Le 05/07/2023 à 12:05
J'ai eu le déplaisir de bosser avec MongoDB pendant un stage, après 2 autres développeurs qui avaient chacun sa conception, et c'était juste l'enfer, des doublons dans tous les sens, aucune cohérence dans les structures...
Maintenant quand je vois ça sur une mission je refuse directement, on a assez de problèmes en bossant avec des technos fiables pour s'en rajouter avec des technos souvent pas maitrisées ou mal utilisées.

PostgreSQL & MySQL ftw
Moi je fais le contraire

Comme le dit Seb_de_lille, les problemes avec Mongo resultent souvent d'une mauvaise utilisation. De mon point de vue, il ne faut pas raisonner de la meme manière qu'en SQL avec une base orienté documents.

Je peux également citer un contre exemple à notre ami Stuart. Le projet,dans lequel j'ai récupéré le lead, utilisait justement Postgres et stockait des données sous forme de json. Mais la manière dont ca avait été fait, faisait qu'au final on avait à la fois les incovénients des bases SQL et les inconvénients des bases document sans avoir le moindre avantage de l'une d'entre elle. Nous avions une api backend et Postgres derrière. Le content type des endpoints etaient en json et il y avait notamment 2 tables interessantes: la table users et la table product. Et fonctionnellement, chaque product était lié à un user. Ca s'est donc traduit dans le code par une table users avec un id, nom, prenom, email, etc... et une colonne pour chacune de ces valeurs. Et dans la table produit, il y avait une colonne id et une colonne qui stocke le json de l'objet produit avec dans le json un champ userId. Et là BOOM, perte de contrainte de clé étrangère. Je pouvais donc sans souci, insérer des produits avec des userId qui n'existent pas. Et toute la cohérence de la base de données reposait sur l'absence de bug du frontend.

A propos du débat SQL vs NoSQL, mon avis est le suivant: dans la grande majorité des cas orienté application web, l'utilisation d'une base SQL me parait excessif car certes les bases SQL ont la flexibilité de pouvoir faire toutes les requetes qu'on veut dans tous les possibles et imaginable mais en meme temps quand on code en suivant les architectures modernes à base d'api REST micro service, la liste des requetes que l'appli execute est connu à l'avance et ont une faible complexité donc on a pas besoin d'une telle flexibilité. Après, si on est sur use case de data analytics ou de datawharehouse, une base SQL me parait bien plus pertinente qu'une base NoSQL.
4  1 
Avatar de shenron666
Expert confirmé https://www.developpez.com
Le 06/07/2023 à 21:41
Le premier problème a toujours été et reste la compréhension des outils à disposition.

combien font l'erreur de penser nosql pour remplacer une base sql en oubliant ou ne sachant pas que le "no" ne veut pas dire "no" mais "not only" ?
de mon point de vue, une base nosql n'est pas un remplacement d'une base sql
soit c'est un choix pertinent pour le besoin exprimé par le projet
soit c'est en complément d'une base sql

chacun son métier s'applique aussi aux composants logiciels
3  0