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 !

Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?
Un développeur pense que vous devez opter pour SQL

Le , par Coriolan

354PARTAGES

23  4 
Quel est selon vous le meilleur SGBD ?
SQL
74 %
NoSQL
7 %
Pas d'avis
20 %
Voter 46 votants
En août dernier, une étude a montré la montée en puissance du NoSQL, avec de plus en plus d’entreprises qui se tournent vers le cloud public. Ce constat peut être expliqué par plusieurs facteurs, notamment la performance des nouveaux systèmes NoSQL qui reste bonne avec la montée en charge (scalabilité) en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse de coûts.

Mais tout le monde ne semble pas être convaincu que le NoSQL constitue une solution optimale et peut remplacer les bases de données SQL. Certains ont même regretté d’avoir opté pour les bases de données non relationnelles au lieu du bon vieux SQL.

Les mauvaises raisons pour choisir NoSQL

Dans son article, Paris Kasidiaris a listé selon lui les mauvaises raisons qui poussent les développeurs à recourir aux bases de données NoSQL. Dans la plupart des cas, ce choix est dû à une connaissance superficielle du sujet.

Plus facile pour les développeurs

Comparer la façon d’écrire un document dans le magasin de données contre l’écriture d’une nouvelle base de données avec INSERT constitue le meilleur moyen pour comparer la facilité d’utilisation de chaque solution NoSQL et SQL. En effet, l’écriture d’un objet JSON directement dans le magasin de données est plus facile qu’avoir recours à une requête SQL INSERT.

Maintenant, si on compare par exemple la façon de récupérer les utilisateurs qui se sont inscrits sur une application durant les 24 dernières heures :

Avec MySQL

Code : Sélectionner tout
1
2
3
SELECT  *
FROM    users
WHERE   signup_time >= CURDATE() - INTERVAL 1 DAY
vs. Mongo

db.users.find({
"signup_time": {
 $gt: new Date(Date.now() - 24*60*60 * 1000)
}
})
Dans le premier cas, on utilise un langage ayant des mots que les humains utilisent pour communiquer entre eux. Le deuxième cas au contraire est écrit en JavaScript, et vous êtes dans l’obligation de créer votre requête avec un objet JSON et même convertir les 24 heures en millisecondes.

Et ce n’est pas fini, si vous voulez récupérer de la base de données tous les utilisateurs qui se sont inscrits la semaine dernière et se sont connectés au moins deux fois, vous êtes dans de beaux draps.

Une simple requête relationnelle comme celle-ci ne peut tout simplement pas être exprimée directement dans un magasin de données NoSQL, mais elle peut être utilisée en SQL (une seule requête SQL ou ORM : mapping objet-relationnel). Pour contourner cette limite du NoSQL, le développeur doit recourir à la dénormalisation, c’est-à-dire la copie des mêmes données dans plusieurs documents ou tables afin de simplifier et optimiser le traitement des requêtes ou pour ajuster les données à la demande pour l’utilisateur. Une autre solution consiste à utiliser MapReduce.

Meilleure prise en compte de la montée en charge

Cet argument est souvent avancé par les partisans du NoSQL, mais encore faudrait-il d’abord que la scalabilité soit un problème pour le développeur et que le NoSQL soit plus performant que les solutions SQL lors de la montée en charge.

D’abord, la montée en charge n’est pas et ne sera peut-être jamais un problème, à part si le développeur doit faire face à des milliers de requêtes par seconde et des terrabytes de données dans sa base de données. Et même au cas où vous êtes amené à un tel scénario, des solutions (fully managed) comme AWS RDS existent.

La deuxième hypothèse est aussi erronée, NoSQL n’est pas plus performant que SQL lorsqu’il s’agit de montée en charge. MySQL est utilisé par quelques-uns des sites web les plus populaires de la planète comme Facebook, Twitter, GitHub, Basecamp et à peu près toutes les installations de PHP. Ces sites comme on peut le constater n’ont pas trouvé de soucis avec les SGBD SQL malgré l’énorme trafic qu’ils reçoivent.

Une vitesse d’écriture plus rapide

Cette supposition est vraie, mais en tant que développeur, est-ce que votre application a vraiment besoin d’écritures rapides ? À part si vous allez exécuter un service de logging ou quelque chose de similaire, dans la plupart des cas, toutes les applications se ressemblent et ont un but commun : une personne propose un contenu qui sera consommé par d’autres personnes. C’est la façon avec laquelle fonctionne le web aujourd’hui, Facebook, Twitter, YouTube, les services de partage de fichiers, votre application ne fera surement pas exception.

Ce sont donc les principales mauvaises raisons qui poussent les développeurs à choisir le NoSQL contre SQL. Ce qui est malheureux, c’est qu’elles sont mises en avant par le site web officiel de MongoDB, un site qui a surement joué un rôle vital dans cette illusion.

Les bonnes raisons pour choisir une base de données SQL

Chaque technologie utilisée a ses points forts et ses points faibles, et SQL ne sort pas du lot. Voici pourquoi SQL est presque le bon choix pour tout type d’application web.

L’écosystème

L’écosystème de SQL est juste imbattable, c’est un langage qui date de 1974, donc plus de 40 ans d’existence. Pour cette raison, les développeurs sont devant un nombre énorme d’outils et de services auxquels ils peuvent recourir.

SQL est enseigné dans toutes les universités et les écoles d’informatique du monde. Les solutions matures de SQL ne manquent pas, de PHPMyAdmin et SQLAlchemy à Pony ORM. Les opérateurs cloud publics proposent également des bases de données SQL en tant que service que vous pouvez utiliser sans effort (Amazon RDS, Google Cloud SQL and Azure SQL Database).

Les transactions et les propriétés ACID

SQL offre une chose que tous les gens responsables d’applications web en production cherchent à assurer, la tranquillité d’esprit à propos de leurs données. Cela est dû au fait que toute solution SQL dans le marché vous permet de regrouper plusieurs requêtes SQL dans des unités de travail conforme au standard ACID (appelées transactions).

En pratique, cela veut dire que vous pouvez entrer des changements sur votre base de données regroupés en une seule transaction. Vous pouvez mener toute requête qui concerne des opérations de transaction, comme start transaction, commit, ou rollback, tout en étant sûr de garantir l’atomicité, la cohérence, l’isolation et la durabilité de votre transaction.

En d’autres termes, avec SQL, vous pouvez être sûr d’arriver à votre objectif sans avoir de mauvaises surprises.

Le stockage

Un autre aspect important des systèmes de base de données SQL pour les applications en production est sa capacité à faire des économies sur l’espace de stockage. En effet, SQL a besoin d’une structure de table prédéfinie pour enregistrer les données. Cela permet d’enregistrer seulement les contenus dans chaque ligne et chaque colonne dans le disque. Au contraire, avec les solutions NoSQL, vous aurez à enregistrer tout le document (toutes les valeurs) sur le disque, puisqu’il n’existe pas de structure prédéfinie pour les documents stockés dans chaque collection. Plus vos données deviennent importantes, plus le problème s’amplifie avec plusieurs gigabytes de données NoSQL.

Cet article ne vise pas à chahuter les magasins de données NoSQL. Loin de là, il y a des solutions NoSQL dans le marché qui sont utilisées dans presque tout type d’application web en production. Il s’agit ici de montrer qu’il ne faut pas considérer NoSQL comme une solution à tous nos problèmes de stockage de données, pour la simple raison que cette solution parait être simple. On a déjà des solutions SQL matures et bien établies qui ont déjà fait leurs preuves et répondent à tous nos besoins en la matière.

Source : stateofprogress.blog

Et vous ?

Que pensez-vous de cette nouvelle tendance qui cherche à forcer l'usage du NoSQL ?

Voir aussi :

Forum Décisions SGBD

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

Avatar de grunk
Modérateur https://www.developpez.com
Le 22/03/2017 à 8:16
Comparer du relationnel et du nosql en demandant lequel est le meilleur c'est comme comparer une formule 1 et un voiture du Dakar.
Les deux peuvent rouler vite , chacune dans leur domaine.

Evidemment que si j'ai un modele de données qui requiert des relations entre les entités , ca serait complètement stupide de partir sur du nosql parce que c'est la mode. Et inversement stocker des données indépendantes avec du relationnel n'est sans doute pas optimum.

Bref c'est un faux débat
14  0 
Avatar de philouZ
Membre chevronné https://www.developpez.com
Le 22/03/2017 à 4:30
Perso je n'utilise pas de NoSQL car je n'en ai absolument pas l'utilité. A mon sens le NoSQL ne peut avoir un intérêt que dans l'utilisation du big data avec un volume de donnée extrêmement important et je ne suis pas encore dans ce cas.

Pour du site web, des appli principalement accès gestion, du développement mobile avec accès par webservices, je n'utilise que du SQL. C'est peut-être aussi parce que je maitrise ce que je fais et que je n'ai pas besoin de me former pour l'utiliser (même si on en apprend tous les jours).

Pour répondre à la question
Que pensez-vous de cette nouvelle tendance qui cherche à forcer l'usage du NoSQL ?
Je pense que ça fait plus effet de mode. Comme beaucoup de choses, ça vient de sortir alors vite tout le monde se précipite dessus et dit qu'il n'y a pas mieux. J'en vois encore qui me disent : "Comment tu n'es pas passé au big data ?".

J'attends les retours d'expériences mais je ne suis pas sûr qu'il y ait tant de monde que ça qui passe au NoSQL. La part restera faible à mon sens.

Chaque outil a son utilité...
9  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 22/03/2017 à 21:40
Alors totalement d'accord sur l'ensemble des arguments annoncés car c'est ce que j'ai egalement pu constater sur une appli type (duree du projet : 1 an) pour laquelle on a voulu evaluer tous les arguments enoncés pour justifier qu'une BDD nosql est plus performante qu'une BDD relationnelle classique.

Au final on est resté sur nos BDD traditionnelles. On a definitivement supprimé l'option de deployer une telle BDD en prod (quand on voit les soucis recents de mongodb). A contraintes equivalentes les BDD traditionnelles n'ont pas a rougir; langage universel et pas barbare (voir mongodb - une horreur).
il n'y a bien que les devs a qui ca plait parce qu'ils n'ont pas a faire de commandes sql et pousse leur json sans s'interroger sur les perfs etc.
Du vecu. un leurre, phenomene de mode pour mon retour d'experience. C'est souvent les developpeurs qui poussent a utiliser cette techno ('c'est genial...') et quand tu grattes un peu pour l'aspect admin etc. il n'y a plus personne.
Sans compte qu'il n'y en a pas 2 qui ont les memes syntaxes. hadoop a la limite me parait plus proche du sql dans la syntaxe. La pire : mongodb
7  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 23/03/2017 à 19:07
Citation Envoyé par sbeex Voir le message

De plus dans le monde réel on utilise très très souvent des ORM et oui l'époque ou on faisait tout en sql avec du pl sql est bien derrière nous ... maintenant on travaille avec des API qui sont les seules à accéder à la bdd donc tout le travail mal propre et difficilement testable qui était fait directement côté bdd s'est vu déporté dans le code. Navré mais dans de nombreuses applications et je parle en connaissance de cause on utilise des ORMs ! Et oui... et je parle pas de petites application bien au contraire
non non, ce mode de fonctionnement n'est pas obsolete et sans conteste le plus efficace encore en 2017. Encore une fois je le vis sur nos projets en intra.
A la base on embauche plutot des dev C# (qui se serve de la BDD comme d'un serveur de fichier) la seule chose les interessant etant de faire des API (a la mode) + tests unitaires a gogo.

Le pb c'est les perfs; la BDD est vue comme un simple stockage.
Toute l'intelligence autrefois definie dans le code embarqué en BDD est fait ailleurs sur le reseau via une URL/Reverse Proxy.
Du coup les A/R et charge reseau est phénomenale; les besoins memoires/puissance de calculs sont enormes; le couplage est fort entre les elements car si l'un des elements fonctionnels n'est pas present, y a plus rien qui marche.
Ah oui, generalement il faut doubler les infras/redondance etc.

Archi SOA donc, terme a la mode. Tout le monde fait des API mais faire des logiciels avec une granularité tres fine ca devient une catastrophe en perf lorsque tu dois faire du traitement de masse (tres bien gere dans du code directement en BDD puisque ca ne sort pas de la BDD).
Dans nos API les données sont recuperees sur reseau (via reverse proxy) sur la BDD, traitées localement (besoins memoires potentiellement importants) puis enregistrées via autre API dans la meme BDD. Dans ces archi SOA on est dans des concepts tres theoriques; en pratique c'est pas on en terme de perf.
Je le vis au quotidien avec certaines de nos nouvelles equipes (developpeurs chevronnés en C# et experts archi Orange) mais on voit aussi quels sont les projets qui ont "toujours des problemes avec l'infra (souvent le coupable lorsque l'usine a gaz SOA ne fonctionne pas ou mal).
A coté nos autres projets codés facon old-school, on deroule sans aucun soucis de perfs.

D'ailleurs notre hierarchie commence serieusement a revenir la dessus car ils voient qu'on deroulent des heures et qu'au final les logiciels ne sont pas plus performants, largement plus couteux et pas plus fiables (malgré les centaines d'heures passées a coder des TU).
7  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 23/03/2017 à 18:43
Citation Envoyé par sbeex Voir le message
Haha merci pour votre tacte Pour ma part je vois surtout un prof qui vit dans son monde académique idéaliste et complètement utopique face à un ingénieur dans la vie réelle.

M'enfin continuez de voler sur votre petit nuage rose

Un profil utilisateur sans champs nullable je pense qu'il faut que vous revoyez un peu les bases du monde réel mon cher monsieur c'est complètement dénué de sens !

De plus dans le monde réel on utilise très très souvent des ORM et oui l'époque ou on faisait tout en sql avec du pl sql est bien derrière nous ... maintenant on travaille avec des API qui sont les seules à accéder à la bdd donc tout le travail mal propre et difficilement testable qui était fait directement côté bdd s'est vu déporté dans le code. Navré mais dans de nombreuses applications et je parle en connaissance de cause on utilise des ORMs ! Et oui... et je parle pas de petites application bien au contraire
Totalement pas d'accord sur l'ensemble de vos remarques. Toutes les fois ou j'ai rencontré des gens utilisant un ORM etaient systématiquement a la recherche de personnes pour les sauver
de situations devenues ingérables (nhibernate/EF) car non maitrise de ce qui est réalisé.

Dans ma boite je le vis au quotidien. Ceux qui font du EF (profils c# et pas BDD) et les autres (ADO.net classique ou les requetes sont maitrisées).
Les resultats sont edifiants.
La maintenance et les situations de crise sont légions pour ceux utilisant les ORM (modele objet C# == super puis rapidement on se rend compte que pour faire meme des requetes les plus simples, ce sont des requetes de plusieurs 10aines de lignes qui sont générées et qui te ramenent tout le modele objet et relations en memoire).
Alors les dev passent ensuite du temps a essayer de comprendre comment fonctionne l'ORM pour le 'tuner'... au lieu de faire du SQL qui ne les interesse pas (jamais compris cette logique de fonctionnement).
Idem pour les bases nosql; ce sont les ememes personnes qui disent que le SQL c'est compliqué et qui se noient dans mongodb et ses syntaxes barbares et inbitables = totalement illogique

Probleme vecu recemment : utilisation Driver Devart+EF = le code generé faisait systématiquement des requetes abominables en terme de perfs = le code C# a ete revu afin qu'il genere le code SQL ciblé (un comble !).
Puis quelques mois plus tard, on doit changer les versions de ces 2 logiciels ... et la encore patatrac, le code generé n'est plus le meme (!!!!).
Donc la solution a ete vite resolue; suppression des couches devart+EF (il n'y avait pas des 100aines de requetes non plus). Resultat : quand c'est maitrisé les perfs sont là; le code est maitrisé; que demande t on de plus ?

Depuis on a banni systématiquement tout ORM et on s'en porte pas plus mal (ne serait ce que pour la maintenance et eviter les situations de crise dans des logiciels qui sont deja des milles feuilles). Pour moi les ORM c'est fait pour cacher la faineantise de certains devs qui ne veulent pas chercher a comprendre ce qu'il font ("l'outil magique".
6  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 28/03/2017 à 11:45
Citation Envoyé par StringBuilder Voir le message
Ca tombe bien avec SQL Server tu rajoute "FOR JSON" à la fin de ta requête SQL, et ça te retourne un résultat formaté en JSON...
Idem avec "FOR XML".
=> Et l'avantage, c'est que la même requête peut produire indifféremment un datatable, du json ou du xml, sans changer une ligne de code
J'ai pas droit à Sql Server (Linux/Docker oblige) mais Postgres aurait été possible. Et je découvre au passage qu'il supporte ce mécanisme de transformation vers JSON, chose que je ne connaissais pas. Donc merci pour l'info!

Citation Envoyé par SQLpro Voir le message
En plus le système est dynamique... Tout ajout de fichier dans l'OS est immédiatement vu par la table et vice versa... Ce que ton pauvre code est incapable de faire !
Bon par internet comme ça vous pouvez pas avoir le contexte précis dans mon cas, à savoir - entre autre - que ni moi ni mon serveur n'a accès à tous les documents (confidentialité). Du coup le fait de fournir un exécutable autonome (en Go) que les personnes autorisées vont lancer sur leurs répertoires pour l'indexation est considéré comme une bonne chose par elles. Mais là n'est pas le sujet de mon code d'exemple.

Mon but était d'illustrer mes propos initiaux sur la simplicité et la flexibilité offertes par une approche sans schéma (couple Mongo + Go). A savoir que ma structure de données est définie telle que j'en ai besoin dans mon code, et que la bdd s'adapte sans rien avoir à faire : "your data is the schema". En particulier j'ai une map de clé-valeurs... si c'est dans ma struct, c'est dans ma base! Et je peux librement spécialiser mon type (par héritage... ou pas!) pour certains cas de documents et là encore, la bdd s'adapte de façon transparente sans m'imposer un modèle beaucoup plus flat. Pour moi, c'est du bonheur.

Car si vous avez vite mis le doigts sur les petites choses qui nous feraient pinailler pendant des jours, vous avez omis de répondre à la question initiale : la gestion de champs "nullable" pour reprendre le terme qui a valu à un malheureux de se faire foudroyer par la colère de Zeus^^. Voici où moi j'en étais resté :
- faire un update de la table c'est crade et lourd
- créer de nouvelles tables à chaque fois c'est encore plus lourd!
- la solution "table poubelle" qui stocke du JSON... à quoi bon? MongoDB propose mieux que ça, en termes de requête, d'indexation, et de stockage (BSON = JSON binaire).

Citation Envoyé par SQLpro Voir le message
Je te conseille donc de te recycler vite et d'aller voir ce dont sont capable de vraies bases de données
Lol. La bdd n'est pas mon domaine d'expertise (voilà qui devrait te rassurer) mais je pense que ce n'est pas le cas non plus de beaucoup d'autres développeurs. Et ne t'en déplaise, la solution que j'ai mise en place répond parfaitement au problème, à savoir: faciliter le classement de 200.000 documents pendant le temps que ça prend par une dizaine de personnes et ensuite... poubelle! (à la base ce sont des feuilles Excel qui étaient utilisées...).

Là en très peu de temps, sans être spécialiste, j'ai un serveur web qui affiche une liste de documents filtrables avec possibilité pour chacun d'entre eux de renseigner des tags ou clé/valeurs au choix. Et le plus long c'est le dev web car la partie bdd a été expédiée en 30 minutes chrono, installation (Docker) du serveur compris!

Bon je suis conscient c'est pas représentatif non plus de l'utilisation classique des bdd. Mais histoire d'essayer d'être un brin constructif (même si c'est pas vraiment le but de ce topic^^), voilà ce que je retiens de nos échanges :
- le modèle NoSQL (à la Mongo) incite à priori davantage le développeur à implémenter la logique côté code plutôt que côté bdd (les SGBDR sont plus puissants à ce niveau là)
- dans la pratique beaucoup de développeurs rechignent à le faire en SQL d'où le succès des ORM
- les spécialistes en bdd s'en désolent mais les développeurs sont contents d'avoir un langage de moins à gérer
- le NoSQL serait donc plutôt à comparer au couple SQL+ORM qu'au SQL "natif"?
- c'est une techno qui est très liée au Web (JSON)
- ce que MongoDB permet de faire en terme de fonctionnalités, un SGBDR sérieux le permet aussi bien voire mieux mais l'inverse n'est pas vrai
- le faire en SQL demande plus de boulot et de réglages
- tout cela s'applique dans un contexte "classique" et non pour du big data, domaine pour lequel le NoSQL est initialement apparu! Comprendre ce dernier point c'est comprendre le choix techniques de Mongo (non ACID...).

Je conclus en disant que j'ai pas fait de SQL depuis 4 ou 5 ans. A l'époque j'avais utilisé Postgres (vues, procédures stockées, triggers...) et avait au final (plusieurs mois d'étude et conception) fait quelque chose de très satisfaisant en terme de robustesse et intégrité des données (au passage, Frédéric, la lecture de tes article m'avait bien aidé ). Et c'est clair que le NoSQL n'a rien à voir avec ça et que c'est une hérésie de l'utilisé pour un tel besoin. Mais en même temps, c'est pas ce qu'on lui demande!

A+
7  1 
Avatar de al1_24
Modérateur https://www.developpez.com
Le 27/03/2017 à 14:30
Entendu sur un projet Agile :
On écrira les spécifications quand le développement sera terminé, comme cela on sera bien en phase.
5  0 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 24/03/2017 à 11:46
Bonjour,

Ne connaissant pas du tout le "NoSQL" (rien que le concept, assorti du nom, me fait fuir), je me pose pas mal de questions.

Déjà, sur la forme (ou le fond, en fait).

"NoSQL" : le SQL étant un langage, je m'attends, sous ce nom, à trouver un "autre langage", ou "pas de langage du tout" (ça va être coton) pour accéder à mes données, quelle que soient leur forme et à la limite, le moteur de données dernière.
=> Le "NoSQL", c'est en fait ce que fait n'importe quel ORM, ou surcouche telle que Linq to SQL de .NET

Mais en fait, quand on creuse un peu, non, pas du tout.
En fait, le "NoSQL", c'est un "NoSGBD" en fait, voir même un SGBD (pour "Système de Gestion de Bordel Désorganisé".

En effet, les inconditionnels du NoSQL, mettent en avant :
- La possibilité de gérer des données non structurées (donc en gros, coder de la merde sans analyse)
- La possibilité de faire évoluer la structure des données dans le temps (donc en gros, ne pas penser à demain quand on code)

Parmi les exemples qui ont pu être donné ici, on parle de :
- Gestion de sessions utilisateur sur un site WEB
- Gestion de documents
- Gestion de données hétérogènes (table poubelle powa)

Ok, alors moi, je suis peut-être stupide, mais si j'aià gérer dans ma base de données des variables de session utilisateur :
=> Je sérialise mon objet en binaire, XML ou JSON, et je le met dans une table de type "clé/valeur".

Si j'ai des documents à gérer :
=> J'utilise une colonne de type varbinary que je vais indexer (sâchant que sous SQL Server par exemple, je peux écrire mon propre filtre d'indexation, qui va être capable de me produire en sortie des données structurées telles que auteur, sujet, date de modif, l'âge du capitaine, couleur du bateau) y compris à partir d'un format totalement propriétaire (cf. mon projet, il y a quelques années, de faire un filtre d'image permettant d'indexer du texte reconnu par OCR dans des images insérées dans la base de données : et en plus ça marchait !).

Si j'ai de la merde à stocker dans une table poubelle, je vais faire pareil que pour la table de session : clé/valeur avec données sérialisées

Si j'ai juste besoin de stocker, je sérialise en binaire (on aura du mal à trouver plus rapide que de stocker et charger des données dans leur format natif).

Et si j'ai besoin de faire des recherches dessus, une sérialisation XML ou JSON me permettra tout à fait de faire des recherches, y compris indexées, sur des données dont la structure diffère d'une ligne à l'autre.

Après, je parle ici de fonctionnalités présentes dans SQL Server, certainement aussi dans Oracle, mais très probablement absentes de MySQL (car j'ai l'impression que le débat "SQL vs NoSQL" c'est surtout "MySQL vs tous les autres poubellarium de la terre".

Suis-je le seul à avoir ce ressenti ?

PS : Désolé si le ton est légèrement trollèsque, après-tout on est vendredi...
5  1 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 24/03/2017 à 14:38
Sinon, je viens de lire l'article Wikipedia sur NoSQL (histoire d'être un peu moins ignare).
https://fr.wikipedia.org/wiki/NoSQL

NoSQL orienté-agrégats
=> C'est typiquement un cas de dé-normalisation qu'on pourra mettre en place dans un datawarehouse : plutôt que d'avoir une base avec tout dedans, on va éclater la base avec des sous-ensembles répondants à un besoin précis

NoSQL orienté-graphes
=> Bon, ben là, je suis pas bien avancé, et j'ai pas le courage de lire l'article en anglais qui est certainement plus complet

NoSQL sans-schéma
=> On est dans la base poubelle, et je ne m'étalerai pas forcément sur ce que j'en pense

C'est certes, succin, mais y'a quand même un truc qui me met le doute...

Quand je lis le laïus à propos de l'abandon d'ACID, je suis en effet pris d'un doute affreux.

Ne serait-on pas face à des développeur qui ne sont pas développeur (stagiaire éboueurs à la limite) qui tente de modifier des données directement depuis un outil de BI, dans un datawarehouse ?

J'ai en effet l'impression qu'on prend le problème à l'envers.

Pour reprendre l'exemple du site e-commerce donné par l'article, afin de répondre plus rapidement à un besoin ponctuel (à savoir, en fonction de ce que j'ai commandé à quelles réductions j'ai droit), je fais chambouler complètement l'organisation de ma base, permettre la perte de données (je comprends mieux pourquoi quand je passe des commandes chez Amazon j'ai que la moitié des colis qui arrivent du premier coup), mais aussi toute la partie comptabilité, gestion des stocks, etc.

Personnellement, quand j'ai une base de données relationnelle d'un ERP (ou d'un site e-commerce, y'a pas de différence notable entre les deux), 99% du boulot de la base c'est quand même :
- de gérer correctement les stocks
- de gérer correctement les factures
- de gérer correctement les commandes (en tenant compte des deux premiers)

Et éventuellement, j'ai un petit "-20%" qui va apparaître à côté des chaussettes parce que le mois dernier j'ai acheté des chaussures...
=> Sauf que ce besoin, pas forcément vital, et qui va certainement évoluer énormément d'un mois à l'autre, si je dois mettre en place un DWH ou autre source de données (en lecture seule) pour le calculer, je ne vais certainement pas remettre en question toute la conception du bignou...

Quand je vois que "google, amazon, ebay, et autres cadors" sont les papas et mamans du NoSQL, vu ce que c'est, j'ai plus l'impression que c'est pour s'en servir de source de données "prémâchées" sur des frontaux fortement sollicités, que pour stocker et gérer à proprement parler la donnée vivante... Si ?

La gestion des stocks d'Amazon sont gérés dans une poubelle avec "p'têt bin que oui p'têt bin qu'non on verra bien si le magasinier trouve ton colis ou pas" ?
Que le truc qui me dit "il n'en reste plus en stock mais celui-là y'en a encore 2 et vu que je t'aime bien tu l'auras à moitié prix" soit géré en NoSQL, je veux bien le croire, mais au moment où je clique sur le bouton "commander", et qu'Amazon se connecte à ma banque pour me débiter, j'ai quelques doutes que ce soit confié à un système qui ne gère pas les règles ACID...
4  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 27/03/2017 à 13:12
Citation Envoyé par sbeex Voir le message
Question de point de vue pour moi ce genre de remarque montre plutôt la fainéantise des gens qui ont appris le SQL et qui n'ont plus eu envie d'apprendre une autre façon de faire leur requêtes

Perso je connais très bien le SQL j'ai commencé par la et oui c'est très bien. Mais un ORM simplifie et structure la communication entre le monde de la prog et celui de la bdd et évite pas mal de désagréments, offre pas mal de souplesse. On peut très bien faire des requêtes très performantes via un ORM suffit de pas être trop c**. C'est clair que si on réfléchi pas à l'impact de faire des boucles de findById() ca va pas aller ! Mais c'est pareil avec du SQL natif... sans oublier les système de cache. J'entend a moins que vous fassiez des applications boursière bien souvent vous pouvez mettre en cache les données et réduire les requêtes !

C'est juste une question de maitrise et de préférence.
lol ! ca me fait penser aux nouveaux developpeurs qui ne pensent qu'agilité et dire aux dev seniors qu'ils ne sont pas agiles ... mais des que tu veux leur proposer quelque chose qui ne colle pas avec ce qu'ils veulent faire, d'un coup ils ne deviennent plus agiles et sont rigides et sa cachent derriere leurs outils qu'ils ne faut surtout pas remettre en cause ou changer.
Le SQL evolue en permanence donc aucun soucis il y a toujours quelque chose a apprendre pas la peine d'essayer de comprendre comment fonctionne un outil qui promet des miracles.
Quand on vient me demander de modeliser d'une certaine façon une BDD parce que ca colle mieux avec le le fonctionnement de tel ou tel ORM (vecu avec EF) ben j'envoie balader c'est evident.

Sans etre grossier et traiter les gens de c** toutes les personnes rencontrées (formations/boulot/autres SSII) sont souvent dans des situations critiques avec les ORM. Je crois que tu es bien la seule personne que j'entends avoir un retour positif sur des gros logiciels en PROD.
Ce que je reproche ce sont les devpt junior qui se jettent sur ces outils sans se poser de questions (ce que je vis dans ma boite; TOUS les prestas qui rentrent sont vendus comme experts C#/Microsoft - pour faire des applis de Gestion de BDD... et au final il faut systématiquement repasser derriere eux car leur appli fonctionne sur le LAN en local mais des que c'est en PROD avec du volume surviennent les problemes et situations de crises.
4  0