Avant tout, il faudrait expliquer où est le problème avec SQL et en quoi ces nouvelles technologies les résolvent.
Version imprimable
Avant tout, il faudrait expliquer où est le problème avec SQL et en quoi ces nouvelles technologies les résolvent.
Voilà mon rapport sur App-Engine :)Citation:
Envoyé par Népomucène
Très clairement pour Google, c'est une question de scalabilité. Quand tu intervient sur une Bdd au mexique, il faut que le serveur au Japon soit au courant. Et vite.Citation:
Envoyé par Traroth2
Ca n'a sans doute pas été prévu comme cela au départ.
J'avais posté quelques liens sur ce thread.
http://www.developpez.net/forums/d75...s/#post4461616
Je pense que les SGBDR restent la référence pour faire du transactionnel ACID, mais que pour les autres cas, il y a des solutions plus adéquates.
J'ai lu les ressources indiqués à droite et à gauche mais sans vraiment trouver de réponse à ce sujet.
J'ai trouvé quelques réponses dans cet article concernant le système Dynamo utilisé par Amazone
Cela ne semble pas être un rejet complet de système des bases de donnée relationnel mais plutôt un système permettant de les découper pour éviter d'utiliser quand ce n'est pas nécessaire un système trop lourd.
Il s'agirait d'un langage de requête permettant de manipuler plusieurs sources de données adaptés à des usages particulier en permettant l'usage des fonctionnalités standards nécessaire à un code de qualité.
Pour résumer, ça ressemble à surcouche qui ne rejette en rien les bases de donnée SQL mais l'intégre comme une source de données parmis tant d'autre.
Sujet très intéressant.
De ma petite expérience des outils de mapping relationnels/objets, je me suis souvent rendu compte que pour quelqu'un qui connait bien le SQL, c'est très frustrant, et que l'on est souvent tenté (voire obligé) de faire du SQL pure ( pour des requête de comptage ou pour tester l'existence de relation par exemple).
Je comprends que les adeptes du tout objet cherchent un moyen de se débarrasser des bases relationnelles, en passant à des bases objets.
Mais la mayonnaise ne prend pas, et les bases objets ont du mal à percer. Peut être à cause de nous, les informaticiens, un peu trop formaté à MERISE et autre méthodologie d'analyse.
Le NoSQL, d'après les quelques liens dans les posts, ressemble à si méprendre au cloud computing. Ne pas savoir ou son ses données, ça c'est le pied :aie:
Bref, attendons de voir ce que ça va donner, si un standard (de fait ou non) en ressort.
Après avoir lu ton compte-rendu, je vais me dépêcher d'attendre ... :DCitation:
Envoyé par nicorama
Oui mais attention, l'utilisation d'outils d'ORM a évidemment un but de construction d'objets et en effet est inadapté à des requêtes "simples". La documentation d'Hibernate par exemple dit explicitement que dans certain cas il vaut mieux passer par du SQL natif.Citation:
Envoyé par jpouly
Cependant, souvent, on peut observer que beaucoup de traitement sont remontés au niveau des développeurs d'application qui oublient que stockage et traitement des données sont deux choses différentes. C'est ce qui peut être inquiétant lorsqu'on voit ce genre de démarche. Combien de développeurs d'applications ont pris part à ces démarches, combien de gestionnaires de données ? Le premier message met bien en avant l'interrogation et la modification, mais une base de données ne se limite pas à ça. Une alternative à SQL est certes à rechercher, mais sans faire table rase de l'existant.
N'est-on pas en train de vouloir faire faire au SGBD des choses qui ne sont pas de son ressort ?Citation:
Envoyé par nicorama
Ce mouvement est bien entendu la conséquence désastreuse de la perte de connaissance sur ce que sont les données et l'intérêt des SGBDR en général comme outil central de toute application gérant des données.
Relisez l'article que j'ai posté sur le développement en base de données épaisse... Bien sur je suis à contre courant. Mais à contre courant du marketing, pas de la technologie....
Posez vous la bonne question, à savoir d'où vient ce mouvement contestataire ?
Il est assez simple de constater qu'il vient de deux horizons bien identifiés : ceux qui prônent le tout objet via notamment Java (un langage en perte de vitesse et désormais "acquis" par Oracle à travers Sun) et quelques autres industriels qui préféreraient vous voir plonger dans leurs solutions captives comme Google !
Quand aux SGBDR "SGBD-attributs/valeurs" ils ont 20 ans de retard. C'est un modèle qui a eu son heure de gloire un peu avant les SGBD relationnels, notamment avec Pick...
Bref, ce débat c'est Darwwin contre le créationnisme. Un mouvement très en vogue aux US en ce moment !
A +
Wow, affirmer ça avec autant de certitude !! en tout cas, pour contredire cette affirmation, on peut se baser sur le sondage des langages de programmation préférés.Citation:
Envoyé par SQLpro
Et puis en Java, on prône beaucoup plus le mapping Objet/Relationnel que le remplacement de SQL (c'est différent non ?).
A noter aussi qu'en .net, il y a l'émergence de la technologie LINK.
Si le SQL n'a pas d'alternative crédible, pourquoi disparaitrait il ?
Si je ne suis pas le raisonnement des anti-SQL, je trouve néanmoins, SQLpro, que tu est gonflé de te poser en seul défenseur de la vérité face à une horde d'escrocs.....
Mon point de vue : il faut un système pour gérer les données. SQL ou un autre. Sauf que SQL, malgré ses défauts, est standard. Perso, je ne vais pas m'emmmnuyer à faire autre chose, parceque ça n'aurait pas de valeur ajoutée. Mais ça ne fait pas de SQL la panaçée : c'est juste un standard qui convient à peu près.
C'est justement ce qui gène fortement les requins aux dents longues qui préféreraient une solution maison et fermée pour vous la vendre et que vous soyez piégés avec pendant des années !!!Citation:
Envoyé par el_slapper
Posez vus la question de savoir combien Google vous fera payer un jour le fait que vos données seront stockées sur ses serveurs et que vous voudriez tout récupérer en local.. Quel sera la coût de cette migration ?
En règle générale, tous nos joyeux développeurs oublient une seule chose : l'inertie représenté par le volume des données... C'est un facteur très important, largement sous estimé, voire non pris en compte dans les projets !
Si on ne peut que constater la réussite des SGBD Relationnels, c'est justement par ce que tout cela se base sur deux faits incontournables :
1) une théorie mathématique jamais encore démentie, même si des "aménagements" ont été réalisé par l'ouverture RO (voir The Third manifesto de Date et Darwen).
2) un langage normatif, qui, même s'il est "victime" de dialectes est somme toute assez portable car il suffit d'apprendre SQL pour être à l'aise sur n'importe quel SGBDR
A +
Je ne vois vraiment pas où il y a débat. J'utilise Hibernate via JPA et je crée ma database en SQL. Ya aucun conflit, les zenfants :?
Je ne vois pas comment utiliser un ORM sans connaitre le SQL, quoiqu'il en soit connaitre les deux ne vous rendra jamais plus idiot.
On peut également constater que les SGBD Relationnels ont leurs limites : le typage statique des données, la structure fixe des tables et des contraintes fortes sur les relations. Ces limites apparaissent d'autant plus que la mode est à la "souplesse" dans la manipulation des données.Citation:
Envoyé par SQLpro
Qui ne s'est pas retrouvé à devoir réécrire toutes ses requêtes SQL suite au changement de type d'un champ, ou le split d'une table en plusieurs ?
Citation:
Envoyé par SQLpro
Les bases XML (dont je ne crois pas avoir vu de représentant dans la liste des participants de cet manifestation??) s'appuient sur des technologies tout à fait standardise et non propriétaire.
entre autres:
XML et XLINK pour les documents et les liaisons
XML SCHEMA pour le typage et la validation
XPATH,XQUERY pour l'interrogation et le requêtage
ces technologies sont de plus très largemment utilisé en dehors du contexte SGBD.
Les SGBD XML ne sont pas axés non plus sur les mêmes besoins.Les SGBDR étant des données fortement "thématiques" alors qu'une base XML native est généralement plus utilisé dans un axe donnée "documentaire".
Donc ne pas pas généraliser à toutes les solutions ne s'appuyant pas sur le SQL
+1Citation:
Envoyé par Thorna
En l'occurrence j'ai compris le contraire. On est en train de vouloir faire faire à d'autres systèmes des choses qui sont du ressort du SGBD.Citation:
Envoyé par Traroth2
Certes, mais il faut aussi reconnaître la réussite de SGBD Non-relationnels comme BigTable ! La manière de fonctionner de Google et le volume de données traité est une réussite en soit.Citation:
Envoyé par SQLpro
Je trouve néanmoins cette fronde anti-SQL (anti-relationnel par extensions) étrange car il me semble que le couple SGBDR+SQL atteint ses limites sur certains cas et volumétries très très particuliers.
Partant de là, je vois de la place pour des paradigmes et des langages d'interrogation alternatifs mais aucune raison valable de se passer de SQL.
Au lieu de se limiter à dire que chez Google et chez facebook ça marche bien est ce qu'on peut nous montrer des études théoriques qui évaluent les performances et les limites de ces modèles nonSql, comme c'est le cas avec Sql qui se base sur la théorie des ensembles ?Citation:
Envoyé par Keihilin