Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
-->Envoyé par _Xavier_
Je peux me tromper, mais 500Gb/s en écriture ça me paraît difficilement atteignable sur les SGBDR actuels, même sans intégrité référentielle.En effet, selon l’ingénieur de Facebook, Avinash Lakshman, son stockage de données fait confiance à Cassandra pour les interrogations, plutôt que de se servir de MySQL. Comme pour mieux justifier son choix il affirme qu’il ne faut que 0,12s pour écrire dans sa base jusqu’à 50Gb de données. Soit 2500 fois plus rapide que MySQL.
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Là encore il faut voir ce qui est socké, comment, pourquoi et comme c'est exploité à la fin. Pour faire 500Gb/s, il faut aussi le matos derrière.
Ces systèmes ont aussi leurs contraintes, parfois physique.
Mais je crois que ce sont des usage différents.
nosql mais ca recouvre quoi en fait.....
ouais, finalement, plutot que de faire des plans sur la comete, j'ai été voir, et ca me fait peur .. j'explique..
il veulent finalement, avoir quelque chose qui gére des tables de stockage mais sans relations entre elles, donc, ces relations (si elles sont necessaires) devront être externalisées dans le programme appelant.
finalement, pour ce qui est de la rapidité d'execution de requetes simples visant à ajouter, modifier ou recuperer du contenu, pourquoi pas, l'equivalent d'un fichier mais accessible depuis javascript.. et oui, javascript, on retrouve les stockages json et compagnies derriére ce nosql.
donc finalement, ce pourrait être une bonne solution, mais dans le cadre d'une demande de stockage et d'accés à des données indexées et sans possibilités de relations..
rapidité, simplicité. et tout ca..
le pendant de la chose, c'est que le sql permet de faire des choses assez magiques dés lors que l'on a pris le soin de reflechir et d'organiser ses données..
ici, l'organisation, la hierarchisation ne sont plus de mises.
on stocke les données et on les lit. point. finalement, ils reinventent le fichier plat
mais accessible depuis un javascript avec les délais d'internet!!!
woawww!!
une autre explication de ce besoin, est la haine de ces gens qui ont appris le javascript et ne peuvent pas acceder à des bases de données depuis le navigateur...c'est un besoin qui pourrait se comprendre, ponctuellement, mais d'un autre coté, le javascript n'est pas fait pour charger le navigateur qui doit rester un afficheur de resultats..
donc, pour moi, c'est du n'importe nawak..
Pour le typage dynamique, il y a ANY/SQL_VARIANT je pense, à confirmer.
Maintenant c'est vrai que c'est pas nécéssairement recommandé ...
Et puis je pense que c'est un peu voulu ce typage statique (performances, sécurité, optimisation de l'espace ?).
Fedora 12 x64 (laptop) - OpenSuSe 11.2 (desktop)
Hébergeur d'images et de fichiers (< 75Mio) gratuit et sans pub
Pour stocker certains types de données non prévu par la norme, tu es obligé de de tricher, en éclatant la valeur sur plusieurs colonnes lorsque le type est complexe et ne se réifie pas en un type élémentaire.
A l'époque, on rencontrait les cas des dates avec fuseau, des valeurs avec unités, des données géographiques... Aujourd'hui il y a eu quelques avancées de faites qui ont conduit à ce que les types manquants soient intégrés.
Sinon pour réchauffer le débat, un récapitulatif des faiblesses du sql :
http://c2.com/cgi/wiki?SqlFlaws
Lors d'une discussion avec un "professionnelle" celui-ci m'a indiqué qu'il n'utilisait plus que JPA, car il en avait marre d'écrire des requêtes SQL.
Traduction : je suis trop mauvais pour écrire des requêtes SQL qui fonctionnent du premier coup alors je prends une alternative qui ne me prend pas la tête.
Je ne dis pas que tous les fans de "noSQL" ne comprennent rien à SQL.
Je ne dis pas non plus que le "noSQL" c'est le mal. Il y a sans doute des cas ou c'est très utile.
Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.
+1
A part le mal réveillé en première page qui a pris ça comme une attaque directe sur MS SQL Server, personne ne tire de plans sur la comète
Oui oui, c'est pas pour rien que BigTable est plusieurs fois cité comme exemple.
ici, l'organisation, la hierarchisation ne sont plus de mises.
on stocke les données et on les lit. point. finalement, ils reinventent le fichier platTu sais, je connais pas mal de cobolistes qui continuent à accéder à DB2 en mode natif et à traiter les tables comme des fichiers plutôt que d'utiliser SQL; ils t'expliqueront le plus sérieusement du monde que SQL c'est n'importe quoi et que l'accès natif est plus rapide (ce qui est vrai à l'échelle du pouième de seconde).pour moi, c'est du n'importe nawak..
Tu parles justement d'organisations des données, et c'est là la clé du problème. L'organisation des données induite par les SGBDR n'est pas la panacée absolue !
Face à de nouvelles problématiques rencontrées par Google ou Facebook, on tombe clairement sur des "faiblesses" du relationnel et il faut envisager de nouvelles approches.
Le problème est clairement que ces nouvelles approches ne se justifient que dans certains cas mais que malgré cela, il y a un risque d'effet de mode dans lequel les incompétents du SQL vont s'engouffrer...
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Ca, c'est pour ma gueule. Réponse d'ingénieur : ça dépend.
J'ai une base contrat et une base produit. Je dois faire une transaction de création/modification/suppression : évidemment, le SQL sera supérieur.
Maintenant, je dois faire un batch qui scanne TOUS les contrats pour des raisons X ou Y(genre une revalorisation annuelle). Je peut faire un ordre SQL (Fetch / for update), ou alors une descente/remontée de base. Les deux solutions ont leurs avantages et leurs inconvénients. Le SQL pur sera plus lent. Le traitement sur fichier sera plus bavard(et il faut de toutes façons garder SQL pour manipuler les produits associés au contrat).
Mais ma conclusion va répondre à ça :
On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non? Dans mon exemple ci-dessus, traiter un fichier plat est plus accessible à un incompétent que faire du SQL pur.
L'objectif, c'est quoi? Vivre dans un monde de bisounounours ou tout est parfait, mais personne n'y comprend rien? Ou bien adopter des solutions plus besogneuses, mais que le commun des mortels saura maintenir?
A mon sens, une solution élégante mais que personne ne sait maintenir est une mauvaise solution.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Ou de faire ne sorte que les personnes soient justes... formés ? S'il y a des incompétents, au lieu de leur filer des boués de secours, ils seraient peut-être mieux de les mettre à la photocopieuse ou les former aux outils nécéssaires.
'fin, perso je suis a fond dans le XML qui correspond bien à mes petits besoins, donc j'ai rien à dire de plus, je réagissait plus à l'idée qu'à la technologie :p
Le truc aussi, c'est que l'être humain est limité. Le nombre de gens intelligents est encore plus limité. Et arrive toujours un moment ou on a plus que des gens limités à disposition. Ce jour là, si on a tout fait de manière trop intelligente, eh bien on se retrouve le bec dans l'eau.
Tu peux enseigner 10 ans le SQL à quelqu'un qui n'a pas la fibre(genre ma femme), la personne n'y pannera jamais rien. Inversement, elle pourrait me donner des cours de dessin pendant 10 ans, ça serait toujours très moche. Nous humains sommes limités - et chacun a des limites différentes.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Il faut que les incompétent puissent être productifs ? J'ai une meilleure suggestion : et si ils se recyclaient ? ou se formaient ?
C'est vraiment quelque chose de formidable dans le monde du développement informatique : l'incompétence est parfaitement tolérée du moment que tu produis !
C'est un peu comme si pour obtenir un diplôme d'architecte (en bâtiment) il suffisait de savoir dessiner.
bref, on s'égare...
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
C'est pas forcément de l'incompétence, mais la force de l'habitude. La solution traditionnelle pour faire de la "persistance objet" en Java c'est:
- Un modèle objet simple (POJO)
- une mappeur Objet/Relationnel (ORM)
- une base de données relationnelle
Cette solution, bien que totalement fonctionnelle est loin d''être idéale : conflit Objet/Relationnel (impedance mismatch), Schéma en double (dépendances vs relations), conversion de type Java/SQL, ...
Et généralement, on se retrouve a recréer un langage de requête "orienté objet" au dessus du SQL, voir a taper directement dans la Base pour remonter des infos (comptage, existence, ...). Bref, beaucoup de boulot pour passer outre les contraintes de la solution "pojo+orm+sgbdr". Parfois on se rend compte qu'il est plus facile de faire un stockage brut des valeurs de l'objet (nom d'attribut+valeur) et d'écrire son propre système CRUD.
Les NoSQListes (!) ne sont pas contre l'utilisation des SGBDR, mais ils sont contre son utilisation à tout prix comme si c'était la seule solution possible.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
JPA n'est pas destiné qu'aux incompétents. Je suis d'ailleurs tout aussi lent en SQL qu'en JPA QL.
Mais quand je refactor mon projet parce que je n'ai pas un supérieur qui me pond de l'UML deux ans à l'avance, avec JPA je n'ai que la moitié, voire le tiers, à modifier. Et en faisant tourner les tests, les erreurs sont bien mieux décrites, genre un truc de de ouf, faut être triso pour pas trouver l'erreur.
C'est un exemple. JPA est plus productifs pour bons et mauvais. Accessoirement, ce n'est pas le seul but : c'est également souvent plus performant quand on veut réutiliser des requêtes (boite de pandore ouverte)
J'attends avec impatience JPA2 qui permettra le typesafe à l'interieur des requêtes.
En fait la finalité est biaisée.
Tous les frameworks, de l'ORM à l'AOP en passant par les collections, le mvc, les fonctions numériques: n'ont qu'un vocation à l'origine : éviter au développeur de ré-écrire la roue.
Seulement, ils répondent parfois à 80% des cas, et c'est pas toujours intéressant de les consevrer et d'essayer de gérer les 20% restant.
Effectivement, c'est aussi une tendance qui "déresponsabilise" au sens où ça cache une partie au développeur. Les problèmes d'adhérence vienne souvent du fait que les outils sont choisis à priori de tout autre raisonnement.
Concernant le SGBD, il a, et à juste raison, fait sa place dans l'informatique de gestion. Maintenant, pour la manipulation de documents, cela fait des annèes que les logiques de fs existent, d'ailleurs FAT et autres en sont la preuve, et on parle de stocker un gros élément indexé par son contenu.
Donc, une autre utilisation.Il faut comparer et juger à périmètre constant.
+1 comme voirs des tables de stockage d'objet serialise. Jamais compris pourquoi.
(désolé je ne sais toujours pas comment faire de bonne citation avec le nom du poster en hautPour le typage dynamique, il y a ANY/SQL_VARIANT je pense, à confirmer.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.
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 ?
Maintenant c'est vrai que c'est pas nécéssairement recommandé ...
Et puis je pense que c'est un peu voulu ce typage statique (performances, sécurité, optimisation de l'espace ?).
Le typage de données dans une BD relationnel ne fait pas partie de la première étape pour une bonne intégrité des données?!?
______________
Never underestimated the browser
Ne jamais sous-estimé le navigateur
Vic Gundotra, Google IO 2009
Je ne suis pas un expert dans le domaine des SGBD, mais je crois que c'est une bonne chose, que de nouvelles solutions apparaissent. Et si en plus c'est plus performant que l'ancien système, alors que demande le peuple?
Tout le monde devrait avoir de l'esprit critique car personne ne pourra m'apporter la preuve de l'absence de celui-ci
Encore une fois, tout dépend de ton projet:
- Si ton objectif originel c'est de construire une base de données, alors effectivement la définition du schéma est la première étape de ton projet.
- Si ton objectif originel c'est de faire de la persistance de données (d'un logiciel), tes données existent déjà "avant" de créer ta BdD. La BdD n'est qu'une solution technique (parmi d'autres). Donc les problématiques d'intégrité, de relations, de typage devraient être gérées coté logiciel et non pas déportées dans la BdD.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Mais je suppose que ta femme est infirmière, secrétaire, caissière ou avocate, voir mère au foyer, pas informaticienne
Dans la mesure où ton boulot c'est l'informatique, t'es censé être callé sur l'info, du moins dans ton domaine... Ca me fait penser au types qui "connaissent" 36 langages, mais en fait n'en maitrise aucun...
Bref, t'as des gens qui sont chimistes et non pas mathématiciens, mais qui doivent tout de même connaître un minimum les maths pour faire correctement leur travail...
C'est un peu comme Vista quoi, 85% des critiques sont infondés et émises par des personnes qui ne savent pas s'en servir / font n'importe quoi dessus.
Bref, j'arrête le troll, et je vous laisse juste une petite histoire (descendre un peu pour la trad en anglais) :p
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager