Discussion :

[echtelion]

Je travaille en informatique de gestion, sur des systèmes petits à moyen. Je ne parlerai donc que dans un contexte d'informatique de gestion (donc non pertinent pour IOT, temps réel, embarqué......)

Historiquement sur SQL Server et MySQL, j'ai testé Mongo sur des petits projets, et j'ai tout de suite adopté.

Notamment car un Mongo est basiquement une base de donnée objet, ce qui évite de passer par un ORM qui "émule" l'objet derrière la bddr.
Par ailleurs, Mongo ne t’empêche pas de faire du relationnel... Tu as juste à créer un "objet" de type "relation", que tu vas gérer de ton coté.
Il y a des index, pour accélérer les recherches et certaines jointures, et tant qu'on n'est pas dans de l'analytique, c'est bien suffisant.

Selon la taille du projet, il faut néanmoins ne pas tomber dans le piège du "tout dans un même objet", et effectuer le découpage (avec les références) en pensant à comment on va interroger la bdd ensuite. Ce qui nécessite une bonne analyse d'origine de l'application... ce qui selon le client n'est pas forcément très facile...
Pas de script de maj... quel pied pour les migrations... tant qu'on ne fait qu'ajouter des champs => même problématique de qualité de l'analyse initiale.

La migration d'un gros projet (tjrs informatique de gestion) s'est faite sans soucis majeurs... jusqu'aux reportings.
Remplacer une méga requête par un algo qui compile les données avant de les envoyer aux moteurs, à requis une attention particulière, et surtout pas eu le choix de faire ça au cas par cas, au lieu de gérer ça de manière générique niveau framework. Pour certains report, du caching et de la consolidation temporelle ont dut être employés pour rester performants.

Bref, dans mon domaine, Mongo est devenu notre database de référence dans la société.
Cela ne signifie pas pour autant que l'on ait abandonné les autres systèmes. Que ce soit pour des usages spécifiques ou pour des contraintes techniques, nous utilisons tjrs SqlServer (authentification, sharepoint, ...) et SqlLite (bdd locale sans installation).

En bref, MongoDB a bien supplanté SQL dans notre cadre technique.
Cela ne signifie pas pour autant que NoSQL est mieux que SQL.

[Madmac]

En bref, MongoDB a bien supplanté SQL dans notre cadre technique.
Cela ne signifie pas pour autant que NoSQL est mieux que SQL.

On ne peut pas abordé le débat de cette façon puisqu'il s'agit de deux types d'outils pour des tâches différentes:

- Les SQL excellente avec des champs types simples et de taille prédéterminé.
- Les NoSQL avec des champs qui sont constitué d'ensemble d'éléments qui peuvent contenir des sous-ensembles de tailles et de dimensions indéterminés.

En résumé je simplifie. Les SQL pour stocker et travailler sur des tables. Les NoSQL pour stocker et travailler sur des arborescences.

[sooli]

Les 2 ne sont pas comparables, le NoSQL n'est même pas comparable à lui-même car il existe plusieurs catégories de NoSQL (clé/valeur, colonne, document, graph).

Pour le NoSQL, je dirais que le manque :

• des requêtes complexe avec une syntaxe basique
• des fonctions d'agrégation
• des jointures
• des transactions entre table (ou "document")
• des contraintes d'intégrité
• d'une norme ANSI/ISO

fait que je préfère le SQL.

Mais je ne nie pas que l'implémentation du distribué dans ces technologies récentes est très très intéressante.

As tu regarde arangoDB?