Discussion :

[al1_24]

Le paradigme généralement associé au bases NoSQL est celui d'une distributivité horizontale : on rajoute des petits serveurs pas trop puissants ni trop cher, et on augmente les performances de manière quasi linéaire.

C'est aussi ce que font les SGBD relationnels qui reposent sur une architecture massivement parallèle (MPP : Massively Parallel Processing) comme Teradata.

[SQLpro]

C'est aussi ce que font les SGBD relationnels qui reposent sur une architecture massivement parallèle (MPP : Massively Parallel Processing) comme Teradata.

Sauf que l'on fait cela (fédération de serveurs SQL) généralement lorsque l'on a épuisé le scaling up (donc sur des gros serveurs)...

A +

[sbeex]

Il serait peut être temps d'apprendre à modéliser correctement !

A +

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

[al1_24]

Mais ce n'est pas parce que beaucoup le font que c'est bien

[sbeex]

Mais ce n'est pas parce que beaucoup le font que c'est bien

Non mais je pense par contre que si de grands projets qui ont plus de 10 ans utilisent des ORM comme hibernate (gestion des trains au niveau national). Je pense que c'est quand même que ça marche très bien

[Zabriskir]

Ça devient intéressant.

[SQLpro]

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.

Cela fait plus de 25 ans que je travaille dans l'univers des SGBDR après avoir commencé développeur puis chef de projet, puis directeur de projet puis à mon compte en tant qu'expert conseil... Et si vous lisez aujourd'hui des choses sur développez.com et avez des débats aussi contradictoire, sachez que j'y suis pour une grande part...

Si vous êtes un tant soit peu curieux, au lieu de dire des stupidités vous pourriez aller sur Internet (peut être ne savez vous pas ce que c'est ???) voir quelques site professionnel comme LINKEDIN ou vous en saurez plus sur moi...

Pour info, j'ai créé de "grosses application" dont j'ai été le responsable du modèle car c'était des systèmes critiques... En particulier le concentrateur du SPC GD (application Aquaréel : gestion des crues du grand Delta du Rhone afin de prévenir des inondations) aujourd'hui repris partout en France et depuis quelques années en Europe. ERP dans le domaine de la santé. GMAO dans le domaine de l’hôpital. Gestion de mutuelle santé. Solution de recherche par text mining dans les brevets et thèses...
Et mes clients actuels s'appellent Géodis, Thales, Alstom, SATEC (l'INSEE du Luxembourg), et bien d'autres dont quelques banques...
Et quand je fait des audits de perf, et que je voit l'utilisation imbécile des ORM, je tue !

A +

[SQLpro]

Non mais je pense par contre que si de grands projets qui ont plus de 10 ans utilisent des ORM comme hibernate (gestion des trains au niveau national). Je pense que c'est quand même que ça marche très bien

ha oui, ben quand on voit par exemple le site tgv.com qui est la pire merde que je cite en exemple depuis 15 ans comme le plus catastrophique des sites web, on peut en effet parler de réussite !!!

A +

[kilroyFR]

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").

[kilroyFR]

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).

[RyzenOC]

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).

+1, mais la solution est pourtant simple, coder encore plus de tests unitaire

[sbeex]

ha oui, ben quand on voit par exemple le site tgv.com qui est la pire merde que je cite en exemple depuis 15 ans comme le plus catastrophique des sites web, on peut en effet parler de réussite !!!

A +

Si vous aviez regardé le drapeau qui se glisse sur mon profil developpez -> on y voit la Suisse. Le service de train le plus ponctuel d'Europe et également un des plus dense ! (soit dit en passant).

Sur le reste je pense que vous ne connaissez pas les ORM suffisamment pour avoir un avis réel. Vous vous cachez derrière votre SQL puriste et c'est très bien mais dommage d'être si fermé au monde quand même Le développement évolue les moeurs aussi.

[sbeex]

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").

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.

[Shepard]

Mais un ORM [...] offre pas mal de souplesse.

On parle de la même chose ?

[StringBuilder]

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...

[CaptainDangeax]

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...

Je ne peux que plussoyer à ton post. Tout ce que j'ai vu du nosql, c'est la gestion du bordel désorganisé. Une vision de l'avenir, des données bien organisées dans des champs bien définis, et même si on veut stocker du document, un fichier par document sur un stockage et une entrée dans une table pour garder la trace, c'est tout aussi performant que tout mettre en vrac dans un gros machin duquel on sera incapable de sortir le fichier voulu en cas de problème, alors qu'on pourra toujours réindexer une arborescence...

[SQLpro]

Si vous aviez regardé le drapeau qui se glisse sur mon profil developpez -> on y voit la Suisse. Le service de train le plus ponctuel d'Europe et également un des plus dense ! (soit dit en passant).

Sur le reste je pense que vous ne connaissez pas les ORM suffisamment pour avoir un avis réel. Vous vous cachez derrière votre SQL puriste et c'est très bien mais dommage d'être si fermé au monde quand même Le développement évolue les moeurs aussi.

Lisez ce que j'ai écrit sur ce sujet, il y a fort longtemps...
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
Pour info j'ai fait plus d'une dizaine d'audit sur des BD "victimes" d'ORM et le constat est toujours le même :
revenir en arrière pour se débarrasser, d'une manière ou d'une autre, des plaies de l'ORM...
J'ai connue deux entreprises d’édition de logiciel qui ont fait faillite à cause d'hibernate. L'une ayant été racheté par le Crédit Foncier de France qui a entièrement refait l'application principale en code Delphi à l'époque en moins de temps qu'avait duré le développement initial avec Hibernate.
Il y a deux ans, le DSI d'une importante compagnie d'assurance du havre a été viré parce qu'il avait tout misé sur hibernate... Les audits ont montré des régressions spectaculaire de performances par rapport à l'ancienne application écrite en Power Builder malgré une batterie de serveur 20 fois plus rapide...
Vous trouverez d'autres exemples dans mes conseils d'optimisation dans cette série d'article :
http://sqlpro.developpez.com/optimisation/

Enfin, lors du master class d'Orsys dont nous avons déjà parlé et qui a eut lieu cette semaine, plusieurs personnes qui y assistaient nous ont donné leurs sentiment sur les performances catastrophiques qu'ils avaient à cause des ORM et notamment d'Hibernate.

Ted Neward disait déjà en 2004 "Object-Relational mapping is the Vietnam of our industry"... C'est hélas tragiquement encore le cas...
http://blog.jonasbandi.net/2011/04/a...e-vietnam.html
https://news.ycombinator.com/item?id=7310077

A +

[SQLpro]

... 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 !...

Le problème est que les SGBDR font naturellement du cache, car toutes les données sont traitées exclusivement en mémoire et pas comme le croient naïvement bon nombre de développeur par des fichiers sur des disques....

Donc, faire du cache de données côté code, sur un SGBDR qui fait du cache de données, je n'en voit pas l'intérêt, à moins que vous n'ayez des actions chez Kingston ou autre fabriquant de RAM !!!

A +

[StringBuilder]

Donc, faire du cache de données côté code, sur un SGBDR qui fait du cache de données, je n'en voit pas l'intérêt, à moins que vous n'ayez des actions chez Kingston ou autre fabriquant de RAM !!!

Là, ça dépend quand même un peu de ce qu'on met en cache (mais pas besoin d'un ORM pour réutiliser un array de données en mémoire).

Un exemple classique, c'est les listes de valeur pour les "catalogues" : si dans un écran de recherche, je peux indiquer une vingtaine d'attributs, tous sous forme de listes déroulantes contenant quelques dizaines de lignes (couleur, taille, matière, etc.) autant stocker ces listes sur le serveur de traitement, voir même le poste client, et éviter de charger 20 x 50 lignes depuis la base de données à chaque chargement de cet écran de recherche.
=> Ces listes n'évoluent pour ainsi dire jamais, donc un cache d'une durée de quelques heures/jours évite un trafic inutile avec le serveur de base de données, et permet, même si le volume de données n'est pas énorme, d'éviter au serveur de conserver en cache ces données inutilement, d'autant que les libellés de ces valeurs ne sont généralement exploités que dans la partie front office (donc ne seront pas chargées en mémoire par d'autres requêtes).

Mais en revanche, pas besoin d'un ORM ou d'une base NoSQL pour charger quelques tableaux en mémoire...

[SQLpro]

Mais en revanche, pas besoin d'un ORM ou d'une base NoSQL pour charger quelques tableaux en mémoire...

On est tout tout à fait d'accord ,et c'est ce que je préconise à mes clients. Et pour ce faire j'utilise une vue qui concatène toutes les listes afin de ne faire qu'un seul round trip...

A +