SGBD : le mouvement anti-SQL s’amplifie ?

Citation:

---

Envoyé par SQLpro

Bref, on fait du neuf avec du vieux en faisant croire que c'est beaucoup mieux que le reste... Cela s'appelle du marketing !

---

En même temps faire du neuf avec du vieux en débinant ce qui est neuf...Cela s'appelle du marketing.

Faut faire attention à ce genre de phrase à l'emporte piéce. Vieux ça ne veut pas dire inutile, recalé, épuisé. Ca veut aussi dire expérience, atout parfois stabilité.

Ce qui est intéressant ce n'est pas la logique finale mais l'inside, les solutions qui permettent de faire de la persistance simple en REST, le volume, les approches.

Voilà.

Si on suivait ce genre de logique, il n'y aurait qu'un langage pour tous, une pensée dogmatique. Ce qui fait avancer l'informatique depuis toujours c'est ceux qui pensent différemment de la masse. Parfois heureusement, parfois non.

Le KV Store n'est pas mort, il a évolué et est devenu la base des architectures de cache distribués, qui au passage sont toutes dédiées à mieux gérer les goulets d'étranglement sur les...sgbd...

Enfin tout ça pour dire qu'en dev c'est toujours facile d'avoir raison en théorie, peux sont ceux qui sortent victorieux de la réalité sans se perdre dans des considérations technologiques qui finalement sont d'une importance très relative.

Citation:

---

Envoyé par B.AF

Vieux ça ne veut pas dire inutile, recalé, épuisé.

---

Je vais légérement dérivé de la question du NoSQL, mais comme il y a pas mal de personnes ici qui ont l'air d'avoir une bien meilleur connaissance que moi du sujet j'en profite.

Le vieux avec du neuf c'est une chose que j'ai vu régulièrement dans pas mal de domaines sur des concepts et toujours en cycle.

Je connais mieux le sujet en voile ou il y a 2-3 concepts de types de coques ou de voile depuis quelques milliersz d'années qui se succèdent au gré des innovation techniques et des nouveaux matériaux possibles.

Pour moi le XML c'est un peu ma même chose (et certaines techno).

L'ancêtre des SGBD c'est des fichiers plats et un SGF.
Les besoins ayant évolué on n'a aboutit à des SGBDR moderne.
Maintenant , avec la démocratisations des SGBD on a aboutit à des choses un peu ridicules où, essentiellement dans un optique web on avait , par exemple,des couples php-mysql pour gérer des données avec un seul utilisateurs en écritures et 4 tables se battant en duel , ridicule :roll:

Les techniques et outils ayant évolués, on n'a obtenu des fichiers XML, avec des systèmes de validations, de sélections, de modifications garantissant une certaine intégrité des données.

On est revenu à un concept précédent pour couvrir d'autres besoins.

Je pense que ce mode de pensée des cycles de concepts en informatiques est plus difficilement visible car nous manquons un peu de recul historique mais je ne le trouve pas choquant

Citation:

---

Envoyé par pseudocode

Si on prend l'exemple des transactions ACID, ce sont des fonctions qu'il est toujours possible de rajouter "au dessus" du kv-store (par exemple avec des techniques de commit en 2 passes).

---

Je pense que tu parles d'une mise à jour en deux étapes type:

1 - pré-stockage du KV dans un état limbo et retour d'une URL de confirmation

2 - confirmation: requête de changement d'état limbo->valid
Ce type de technique permet surtout d'avoir une idem potence des opérations de creation et d'update.

Je ne suis pas certain qu'il soit judicieux de les comparer aux transactions d'un SGDB-R qui permettent l'atomicité d'un read A,B /modify A.V/update B.V avec une idée de banquier: je retire X à A.V pour les ajouter à B.V en souhaitant préserver l'invariant A.V + B.V.

Je ne pense pas qu'il soit raisonnable de faire la guerre entre les proSQL et les contre: il y a des tas de choses que les BDD SQL font très bien depuis des lustres. Par contre nous avons aujourd'hui des tas de nouvelles applications qui génèrent des "données de références" auxquelles on souhaite accéder rapidement pour la construction d'état ou de suivi divers.

Le modèle de données le plus approprié dans ce cas est proche d'un WebLog: on regarde s'il y a eu des mises à jour ici ou là et on construit un tableau de la situation qui produit... divers état.
On peut toujours utiliser un SGDB-R pour faire çà mais les engins de type KVP sont beaucoup plus adaptés.
-W

Citation:

---

Envoyé par pseudocode

On parle de stocker/indexer/rechercher d'énormes quantité de données.

---

Mais encore ? un nom d'éditeur ? un nom de soft ?

Citation:

---

Envoyé par pseudocode

C'est utilisé par des petites startup du genre Amazon ou Google. :D

---

:mouarf:
Arf, on les sort à toutes les sauces ceux là, mais tu n'as pas oublié yahoo, ebay ...etc...:roll:

Serait ce trop indiscret de te demander tes sources ?

Citation:

---

Envoyé par voran

Mais encore ? un nom d'éditeur ? un nom de soft ?

:mouarf:
Arf, on les sort à toutes les sauces ceux là, mais tu n'as pas oublié yahoo, ebay ...etc...:roll:

Serait ce trop indiscret de te demander tes sources ?

---

Post #9 et #25 de la présente discussion. ;)

Hello

C'est un peu hs, car apparemment aucun des systèmes présentés ici (bigtable dynamo ect) ne s'appuie dessus.

Je pensais à db4o
Avec un ptit bench, à prendre avec des pincettes me direz vous, mais je n'ai pu trouver plus interessants...
http://www.db4o.com/about/productinf...on/benchmarks/

Mais dans l'esprit noSQL, ils sont pas mauvais.

Ce genre de technos peut elle prétendre à un avenir ?

a plus

Le pointeur vers db4o est intéressant, merci.

Si j'ai tout compris c'est une BDD orientée objet, i.e. une façon de résoudre les soucis d'adaptation entre modèle objet et relationnel.

Personnellement, je ne suis pas certain qu'il faille les résoudre "en général": dès que le modèle de donnée est "compliqué" difficile de pas séparer le modèle de la persistance de celui des applications qui utiliseront celle ci.

Et une fois que les deux sont séparés, il faut bien recoller les deux... Argh.

Les applications "simples" sont celle où il n'est pas nécessaire de séparer. Un ORM de type Active Pattern ne devrait pas être trop mauvais dans ce cas.

Mais il est vrai que la question est peut être hors sujet ici sinon que le succès du noSQL est peut être en partie du au fait que nous développons de plus en plus d'applications "non-simples".
- W

Un cas d'utilisation de base NoSQL intéressant, proposé par Ayende Rahien qui est loin d'être un novice des bases de données : http://ayende.com/Blog/archive/2010/...l-dragons.aspx

Un avis anti NoSQL (en anglais) :
http://teddziuba.com/2010/03/i-cant-...ql-to-die.html

Citation:

---

Envoyé par Waldar

Un avis anti NoSQL (en anglais) :
http://teddziuba.com/2010/03/i-cant-...ql-to-die.html

---

Dans cet article, l'auteur tient à montrer que le NoSQL ne doit pas être utilisé partout, prenant pour preuve que tout le monde n'est pas Google, et que même ce dernier utilise des bases SQL. Je pense que tout le monde dans le mouvement NoSQL est d'accord avec ce principe.

Pourtant, je ne vois pas ce qui lui fait titrer que le NoSQL ne devrait être utilisé nulle-part. Ce n'est pas parce que ca ne doit pas être utilisé partout que ca doit mourir.

C'est curieux cette manie qu'on les développeurs a penser en binaire. :?

Une autre opinion sur le sujet
Faut-il en finir avec la mode NoSQL ? Ou est-ce plus qu'une simple mode passagère ?

Personne ne fait la différence entre la Théorie Relationnelle et le SQL, les partisans du "NoSQL" jettent le bébé avec l'eau du bain.

Que reproche-t-on réellement aux SGBD SQL actuels ?

Pourquoi ne pas investir dans des SGBD réellement relationnels (TRDBMS: Trully Reational DBMS) basés sur des langages comme le Tutorial D ?

Citation:

---

Envoyé par Oishiiii

Personne ne fait la différence entre la Théorie Relationnelle et le SQL, les partisans du "NoSQL" jettent le bébé avec l'eau du bain.

Que reproche-t-on réellement aux SGBD SQL actuels ?

Pourquoi ne pas investir dans des SGBD réellement relationnels (TRDBMS: Trully Reational DBMS) basés sur des langages comme le Tutorial D ?

---

Les partisans du NoSql rejettent simplement l'utilisation systèmatique de SGBDR dans l'informatique actuelle.

Le SGBD aujourd'hui présente de vrais problèmes :
Testabilité
Montées en charge
Implémentation propriétaires
Oligopoles dans les environnements pro (2 solutions font plus de 60% du marché !)

C'est un nom "buzz"; mais sorti de cela, il n'y a pas besoin d'avoir quelque chose à reprocher au SGBD pour essayer d'y trouver des alternatives.
L'alternative doit exister ne serait-ce que pour la sanité des développeurs : on ne peut pas se contenter d'une vérité absolue sur le stockage de données.

Se départir de SQL? Bin ca va pas etre simple.

Citation:

---

Envoyé par B.AF

Le SGBD aujourd'hui présente de vrais problèmes :
Testabilité

---

En quoi l'utilisation d'un SGBDR n'est-elle pas "testable" ?

Citation:

---

Montées en charge

---

Il est tout à fait possible de tester cette montée en charge avec des procédures qui remplissent automatiquement une BDD.

Citation:

---

Implémentation propriétaires
Oligopoles dans les environnements pro (2 solutions font plus de 60% du marché !)

---

Mais rien ne t'empêche de ne pas faire appel aux deux monstres. Il y a de la concurrence payante (ex. : IBM DB2) et gratuite (ex. : Postgresql et, sous certaines conditions, MySQL).

Citation:

---

C'est un nom "buzz"; mais sorti de cela, il n'y a pas besoin d'avoir quelque chose à reprocher au SGBD pour essayer d'y trouver des alternatives.

---

Mouais, pourquoi pas, si ça vous amuse...
Tu peux aussi chercher une alternative au marteau pour planter un clou. Pas sûr que ce soit aussi efficace !

Citation:

---

L'alternative doit exister ne serait-ce que pour la santé des développeurs :

---

Je ne vois pas en quoi utiliser un SGBDR est dangereux pour la santé ! 8O

Citation:

---

on ne peut pas se contenter d'une vérité absolue sur le stockage de données.

---

Il y a effectivement d'autres solutions pour stocker des données. Plus rapides, plus simples, à la portée du premier venu... jusqu'au jour où, le volume et la complexité des données grossissant, c'est tellement le bordel qu'il faut tout refaire ! :aie:

Mais c'est vrai qu'on peut faire du stockage de données avec un tableur, avec un fichier texte, avec du XML...

On ne prend pas un marteau pilon pour écraser une mouche mais ça reste l'outil idéal pour former certaines pièces métalliques en grand nombre.

Citation:

---

Envoyé par CinePhil

Il y a effectivement d'autres solutions pour stocker des données. Plus rapides, plus simples, à la portée du premier venu... jusqu'au jour où, le volume et la complexité des données grossissant, c'est tellement le bordel qu'il faut tout refaire ! :aie:

---

C'est marrant, c'est exactement le propos du NoSQL. :D


Quand à l'utilisation des SGBD partout, j'attends toujours qu'on me donne une réponse objective sur la nécessité d'utiliser la théorie relationnelle pour le stockage du cache de Firefox.

Citation:

---

Envoyé par pseudocode

Quand à l'utilisation des SGBD partout, j'attends toujours qu'on me donne une réponse objective sur la nécessité d'utiliser la théorie relationnelle pour le stockage du cache de Firefox.

---

Personne n'a jamais prétendu cela. Personne ne vous dira qu'il faut utiliser un SGBDR partout et pour tout !
Pour ma part il m'arrive même de prôner encore COBOL pour sa rapidité d'accès aux fichiers et FORTRAN pour le stockage des données de calculs (la gestion des overlay en fortran n'a pas d'équivalent en terme de puissance de calcul vs concision des données...).
Le problème est qu'un certain nombre de personne utilisent des SGBDR à mauvais escient et viennent s'en plaindre après.
Je citais dans mon papier "darwinisme" l'article de Laurent Bédé.
Ce monsieur faisait des traitement temps réel de transaction financière et disait qu'il n'aurait pas pu le faire avec un SGBDR ? Est-ce le rôle d'un SGBDR que de faire du temps réel comme le pilotage d'une fusée ??? (on se marre !)

Quand vous lisez dans wikipédia la phrase suivante :
"Le meetup NoSQL de San Francisco du 11 juin 2009 a été particulièrement important pour le développement de cette tendance. Plus de 100 développeurs de logiciels ont assisté à des présentations de solutions telles que..."
On se bidonne !!! Dire qu'un meeting international réunissant 100 pékins a été important me parait un contresens absolu !!!! (http://fr.wikipedia.org/wiki/NoSQL/wiki/NoSQL)

Enfin, dernière remarque :

"
Il est remarquable de constater que tous les acteurs du mouvement nosql sont concentrés autours des géants de l'industrie informatique auquel le marché des bases de données relationnelle échappe, parce qu'il est concentré sur les trois grands éditeurs que sont Oracle, IBM et Microsoft. Il est non moins intéressant de savoir que parmi ceux qui prétendent offrir une solution nosql certains utilisent pour le stockage final des SGBD relationnels ! Enfin, la plupart des alternatives proposées ressemblent aux bases de données multivaluées qui ont été abandonnées à la fin des années 80 du fait de leurs mauvaises performances tant dans l'extraction de données qu'en matière d'écritures. Or le stockage en ligne des données constitue un marché lucratif, sensible et stratégique notamment par le fait de l'inertie inhérente au stockage des données. Il convient donc de se poser la question de savoir si ce mouvement est un effet de mode, une action mercatique de groupe ou bien relève d'un intérêt technique réel...
"

Ces propos sont les miens, mais ont été retirés de wiki... Vous parlez de lobying ???

A +

Moi ce que je remarque surtout autour de moi, c'est un relachement général de certains développeurs sur le traitement des donnée et je n'ai pas l'impression que cela viennent que de chez moi puisque certains sont de nouveau venu quasi sorti de l'école.
Alors qu'on évolue vers des données de plus en plus partagée et du décisionnel à tout va, voir même bien plus avec le WEB et rdf, j'observe des développeurs qui ne voient leur données qu' à travers leur application.
On obtient ainsi :
- des schema de base de données qui sont conçus uniquement par des schéma UML et qui change au gré des évolution de ceux-ci (ce qui fait en effet que personne d'autre que leur application ne peut utiliser leur BDD à part au travers de Web Service qu'ils mettent des mois à fournir et je ne parle pas des pb de maintenances)...
- Des schemas sans aucune contrainte sur les données tout étant au niveau du "framework" d'accès ,puisqu'on n'écrira jamais dans la BDD sans passer par l'application...ce qui bien sûr est faux puisqu'il y a régulièrement des modifications massives à effectuer qui passe par du SQL ,sans aucune sécurité donc(et ils ont déjà réussi à corrompre leurs données avec ça... :roll:)
- une absence totale d'optimisation : genre "C'est quoi un index?"(non,non je ne blague pas malheureusement :cry:) avec des requêtes de lectures qui font planter la base ...
- une méconnaissance totale du fonctionnement d'un SGBD moderne, j'ai appris récemment à un de mes jeunes collègues qu'en utilisant des outils comme SQL Loader on pouvait charger des fichiers de données sans passer par une "application" type JAVA, .NET ou autres...

Mais ce que je constate aussi c'est que ceci n'existe pas que pour les technologies SQL.
Les principaux problèmes que j'ai rencontrés en XML viennent de fichiers constituer à la va-vite, sans aucune réflexion sur leurs données contenues et leur contraintes, ce qui les rends très complexes leur utilisation hors du cadre ultra-spécifique de leur conceptions.
Pas de regles, de contraintes de modifications, le bordel général quoi...

Je suis tout à fait pour le développement des techno NoSql, j'en suis plus ou moins un représentant, mais j'ai vraiment l'impression que son succès est dût à de mauvaises raisons. Un peu trop des personnes concernées me semble vouloir migrer pour supprimer des contraintes sans comprendre que les contraintes ne sont pas dut au système relationnel mais simplement à leurs données.

C'est tout à fait ce que j'ai écrit dans mon article cité ci avant sur le darwinisme, mais je trouve que tu ne pousse pas assez ton analyse.
En définitive tu devrais conclure que lorsque l'on a mis une jambe de bois (no sql) à la place d'une vrai jambe, y mettre un pansement ne servira à rien !!!
Cautère sur jambe de bois.
Autrement dit remplacer quelque chose que l'on a mal fait par quelque chose d'autre qui est encore plus sale, à toutes les chances de produire encore moins de bons résultats !!!!

A +

On en reviens toujours au même constat: un problème d'incompétence, d'ignorance finalement ?
Pour acquérir de solides connaissances sur les fondations des SGBDR, les bases de la théorie relationnelle, il faut fournir un certain effort personnel (par exemple acheter un livre de Chris Date, étudier, s’exercer, réfléchir un minimum), ce que presque personne (et surtout pas les développeurs) n'est prêt à faire.
Pourquoi faire l’effort d'apprendre cela ? La BDD n'est qu'un vulgaire espace de stockage, je suis de toute façon assez compétent dans ma techno (Java, C#, etc..) pour tout réaliser dans l'application.
On arrive très facilement à du grand n'importe quoi, mais ça ne pose pas de problème puisque "ça fonctionne".

Fabian Pascal n'est pas très optimiste:

No surprise there. The database industry has been taken over by vociferous ignoramuses who are selling crappola to other ignoramuses and everybody's happy because ignorance is bliss. Expect this to become even worse; there is no bottom.

This is a consequence of the total collapse of the educational system, and hardly the most critical one[; just look at the state and path of the country]. The dismissal of knowledge and reason is dooming western society in general and the american empire in particular, with the barbarians at the gates.

Pour rejoindre SQLPro sur l'histoire des SGBD:

The history of the field should be an obligatory part of computer science curriculum, but I won’t hold my breath. The academia is increasingly focused on product training for vendors rather than on education.

Those who forget, or dismiss the past ...

A note on programmer knowledge
Note on programmers and data fundamentals
Une étude intéressante à lire, sur le fait d'être incompétent et la difficulté de s'en apercevoir:
Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments