+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 5 12345 DernièreDernière
  1. #1
    Expert éminent sénior

    Inscrit en
    juillet 2009
    Messages
    3 407
    Détails du profil
    Informations forums :
    Inscription : juillet 2009
    Messages : 3 407
    Points : 147 994
    Points
    147 994

    Par défaut Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est un must ou une mode ?

    Mise à jour du 09.07.2010 par Katleen
    Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?


    Une équipe de développeurs passionnés (du site DZone) vient de publier une carte de référence intitulée "Débuter avec NoSQL et l'extension de données".

    Les bases de données NoSQL (et les technologies opérationnelles sur les données associées) sont en effet désormais incontournable pour les développeurs web. Elles sont largement utilisées pour les grandes boutiques en ligne et commence à se faire une place dans les infrastructures IT.

    Donc, cette carte de référence est là pour aider les professionnels à se poser les bonnes questions concernant les implémentations spécifiques de NoSQL ; tout en apportant les outils de base pour identifier les différentes technologies NoSQL et les utiliser.

    Source : Getting Started with NoSQL and Data Scalability (PDF)

    Trouvez-vous cette refcard utile ?

    Pensez-vous qu'un développeur doive maîtriser le NoSQL, ou bien n'est-il qu'une mode passagère ?

    Faut-il en finir avec la mode NoSQL ?
    Ou est-ce plus qu'une simple mode passagère ?


    La question est volontairement provocante. Elle est posée, en des termes encore plus crus, par Ted Dziuba dans un billet intitulé « I Can't Wait for NoSQL to Die ».

    « Certains ingénieurs pensent que l'évolutivité et l'architecture sont la solution [de tous les problèmes]. C'est comme cela qu'est né le mouvement NoSQL », y écrit-il. « L'idée développée avec NoSQL est que toutes les bases de données relationnelles, telles que MySQL et PostgreSQL, sont caduques et que les bases de données fondées sur des documents ou les bases de données sans schéma représentent l'avenir».

    Une position qui irrite visiblement l'auteur pour qui NoSQL est avant tout (pas que, mais avant tout) un effet de mode : « Peu importe bien sûr que MySQL ait été la solution parfaite pour absolument tout jusqu'à très récemment […] Peu importe que de véritables entreprises stockent toutes leurs données dans de vraies bases de données SQL, (pour les lecteurs de la Silicon Valley, Walmart (NDR : équivalent de Carrefour) est une vraie entreprise, pas Twitter) », aujourd'hui, MySQL serait injustement éclipsé par NoSQL.

    Dans le cas d'une montée en charge liée à une forte utilisation, Dziuba explique que la solution fondée sur MySQL peut rencontrer quelques problèmes de performances et qu'« à ce stade, un développeur qui valorise la dernière technologique à la pointe plaidera en faveur de "réécrire le tout en un week-end avec Cassandra" .[...] Et donc, comme par magie, vous avez changé votre stockage de données de MySQL à Cassandra ».

    Tout devrait mieux fonctionner.

    « Eh bien, non ! Saviez-vous que Cassandra nécessite un redémarrage lorsque vous modifiez la définition d'une colonne dans une table ? Et oui, les développeurs de MySQL avait effectivement réfléchi à la façon de mettre en œuvre un ALTER TABLE, mais pour Cassandra c'est un problème difficile car cela représente bien peu de cas ».

    Et Ted Dziuba d'en conclure que NoSQL n'est certainement pas la solution miracle que certains voudraient faire croire. Migrer d'une solution MySQL à une solution NoSQL reviendrait plutôt à « échanger une liste de limitations et de bugs connus pour [...] une liste de limitations et de bugs inconnus ». Avec un risque énorme pour l'entreprise.

    Et c'est bien là où le bât blesse. Car se bercer d'illusions sur NoSQL et mal cibler les besoins de la majorité des sociétés pourrait être très dangereux : « Développer une application à une échelle comparable à celle de Google est un gaspillage de votre temps. […] Ce n'est pas que vous n'êtes pas assez intelligent pour le faire, c'est que vous n'avez pas l'expérience suffisante pour savoir quels problèmes vont se poser à cette échelle ».

    Seul Google aurait donc besoin de solutions NoSQL ? A en croire Ted Dziuba, même pas.

    « [Saviez-vous] que Google AdWords est implémenté sur une base MySQL ? Le cœur de métier le plus critique de Google[...] n'utilise pas BigTable? Et non. En fait […] Google identifie les problèmes avec InnoDB et applique des correctifs au lieu de dire "MySQL n'est pas bon à cette échelle, il faudrait le remplacer par autre chose" ».

    Alors quel avenir pour NoSQL ?

    « NoSQL ne mourra jamais », nous rassure Ted Dziuba. Pour mieux ré-attaquer : « mais il finira par devenir marginalisé, de la même manière que Rail a été marginalisé par NoSQL ».

    Une prophétie qui, on s'en doute, ne trouvera que peu d'échos positifs dans la communauté NoSQL.

    Mais alors, qui croire ?

    Le chant prometteur des sirènes du NoSQL ? Ou l'humour doux-amère du très septique Ted Dziuba ?


    Source : Le billet de Ted Dziuba


    Lire aussi :

    Twitter adopte la base de données Cassandra
    Le mouvement anti-SQL s’amplifie-t-il ?

    Les rubriques (news, tutos, forums) de Developpez.com :

    MySQL
    PostgreSQL
    Et tous les SGBD

  2. #2
    Membre du Club
    Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    36
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 36
    Points : 45
    Points
    45

    Par défaut

    Personnellement, je n'ai pas encore expérimenté le NoSql et je me demande encore comment construire une architecture solide sans le modele relationnel .

    Mais de ce que j'ai pu apprendre sur le mouvement NoSql, il ne vise absolument pas a contrer MySql, mais a proposer des alternatives pour des cas particuliers.

    Je ne pense pas que ce soit une menace mais plutot un complément.
    Ça me rappelle un peu Windows vs Linux... J'aimerai croire que Linux prendra le dessus sur windows très bientôt, mais cela reste un systeme en marge face à Windows qui est bien assis sur ses positions. Je trouve que c'est comparable à MySql vs NoSql...

    Néanmoins j'espère avoir l'occasion de tester ces bases pour m'en faire une idée plus juste

  3. #3
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 1 937
    Points
    1 937

    Par défaut

    Personnellement, j'ai l'impression que les services qu'on attend de ces nouveaux systèmes de persistance, c'est essentiellement des trucs gérés en principe par des surcouches de la base, comme la réplication de données.
    Quant au langage SQL proprement dit, je ne comprends pas ce qu'on lui reproche. Ces nouveaux systèmes (pas encore eu le temps de trop regarder) doivent bien avoir un langage d'interrogation eux aussi. SQL marche très bien et permet de gérer tous les cas. Ça revient à réinventer la roue. Je dis ça, car j'ai vu quelque part comme justification au NoSQL que SQL serait "difficile à apprendre". Pas évident qu'un nouveau langage d'interrogation soit plus simple. Personnellement, je fais partie des gens qui pensent que l'informatique, c'est un métier...

    Cela dit, le mouvement NoSQL est intéressant dans le sens où il permet peut-être de faire émerger de nouvelles idées de fonctionnalités à intégrer aux SGBD. Toute idée est bonne à prendre. Mais sinon...

  4. #4
    Membre confirmé Avatar de saad.hessane
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2008
    Messages
    315
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2008
    Messages : 315
    Points : 499
    Points
    499

    Par défaut

    Moi je pense que la concurrence c'est bien, et que tout le monde aille dans la même direction c'est mal. Oui SQL est super, oui il est simple à apprendre, oui les bases de données modernes offrent des mécanismes d'optimisation du parsage et de l'exécution de la requête. Mais il faut laisser la chance à d'autres idées émerger.
    Et pour info, il y a plusieurs cas où l'utilisation du SQL n'est pas judicieux, comme le développement pour mobile par exemple.

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    février 2004
    Messages
    199
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 199
    Points : 95
    Points
    95

    Par défaut

    Je suis de l'avis de Hayaxx. Beaucoup prennent NoSQL pour un groupe de névrosés qui remet en question les bases de données conventionnelles en totalité.

    En fait, cela n'est pas vrai. L'objectif est de faire bouger les choses dans le monde des bases de données. Ces dernières années les leaders du marché des BDD se sont endormis sur leurs lauriers.

    On remarquera une sorte de stagnation d'un point de vue architecture interne et capacités de traitement.

    NoSQL tente de faire bouger les choses et répondre aux nouveaux besoins qui ne sont pas supportés sinon de manière bizarre dans les bases de données conventionnelles. Exemple :
    - interrogation de documents structurés. Beaucoup diront que cela est déjà supporté. Mais dans les faits c'est tout autre chose.

    De manière plus générale, NoSQL vise à faire avancer les choses sur 2 points :
    - Monté en charge à terme totalement synchrone ;
    - stockage, indexation et interrogation d'entités complexes ; telles que des images, vidéos, cartes routières, etc.

  6. #6
    Membre expert
    Avatar de Emmanuel Lecoester
    Profil pro
    Inscrit en
    février 2003
    Messages
    1 489
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : février 2003
    Messages : 1 489
    Points : 3 450
    Points
    3 450

    Par défaut

    NoSQL versus SGBDR ? C’est à la mode en effet !

    Maintenant c'est une mode, les SGBDR existent depuis bien plus longtemps donc attendons que la mode soit passée.

    Ces idées ne viendraient-elles pas aussi du fait que l'espace disque coute de moins en moins cher et que donc d'avoir des données totalement dénormalisées revient dans l'air du temps (bientôt on aura des fichiers texte )
    Emmanuel Lecoester
    => On recrute des rédacteurs WinDev

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 2
    Points : 10
    Points
    10

    Par défaut

    Pourquoi est-ce que NoSQL serait une mode ?

    N'est-ce pas tout simplement une réponse possible dans l'aspect persistance ?

    Je me rappelle d'une époque pas si lointaine ou le stockage et la persistance n'utilisaient pas des SGBR. Et je ne parle pas d'applications personnelles en environnements pré-web 1.0, mais de solutions professionnelles utilisées par exemple dans des environnements financiers (boursier ou bancaire).

    Pendant longtemps on concevait avec des modèles mixtes, mélangeant stockage mémoire et disque, par exemple avec des systèmes ISAM.

    Et puis et arrivé le SQL qui permettait de tout stocker et de définir, à postériori tout champ comme clé d'accès à l'information, avec bien évidemment les dérives connues de lazzy indexing.

    Et on s'est donc mis à chercher plus seulement par les colonnes principales, mais par tout champ présent dans une table.

    Pire on a monté ceci en paradigme suprême, le SQL permettait tout.

    Je pense sincèrement que l'initiative NOSQL est un retour à des sources plus saines et quelque part plus pertinentes.

    A ceux qui doutent de l'applicabilité de NOSQL dans leur environnement de travail de tous les jours, je demanderais juste que se demander qu'elles soient les clés d'accès aux informations que leur processus traitent tous les jours ?

    Un identifiant client, un code valeur ISIN, une référence d'article ?

    Est-ce que ce type d'information ne pourrait être pas stocké en NOSQL avec une réconciliation dans la partie applicative (Java, C/C++, .NET) ?

    Il serait bon que les plus âgés parmi les réfractaires à NOSQL se rappellent qu'ils ont produits des applications et solutions avant que les SGDBR n'envahissent nos contrées et ne se répandent dans l'esprit des développeurs puis des utilisateurs.

    NOSQL est une approche pertinente et efficace dans de très nombreux cas d'applications, où souvent un SGDBR est sur/sous-utilisé par rapport au besoin réel en terme de persistance.


    Bien amicalement.

  8. #8
    Membre du Club
    Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    36
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 36
    Points : 45
    Points
    45

    Par défaut

    Voila un article tres clair sur les principes et les buts du NoSql pour ceux qui n'en auraient pas trouvé : http://5.freshminutes.it/2010/02/17/...Java%2B&%2BIT)

  9. #9
    Membre éclairé Avatar de metagoto
    Profil pro
    Hobbyist programmateur
    Inscrit en
    juin 2009
    Messages
    646
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Hobbyist programmateur

    Informations forums :
    Inscription : juin 2009
    Messages : 646
    Points : 782
    Points
    782

    Par défaut

    Ça me rappelle un peu ce qui s'est passé avec l'arrivée de l'OOP (même si je n'étais pas né ), de java, de ruby on rails, etc. (et plus tard, le Cloud).

    Beaucoup de hype, des success-stories, des échecs et puis finalement les choses se tassent. La raison l'emporte.

    Les solutions "NoSQL" ont leur rôle à jouer, tout comme le reste.

  10. #10
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 017
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 017
    Points : 16 017
    Points
    16 017

    Par défaut

    Citation Envoyé par Emmanuel Lecoester Voir le message
    Ces idées ne viendraient-elle pas aussi du fait que l'espace disque coute de moins en moins cher et que donc d'avoir des données totalement dénormalisées revient dans l'air du temps (bientôt on aura des fichiers texte )
    Oui, l'espace disque est une des raisons.

    Mais il faut remonter aux origines de ce problème :

    1. la durée de rétention des données

    et son corolaire :

    2. la volumétrie des données stockées

    et finalement son impact :

    3. la performance d'accès en fonction de la volumétrie

    La durée de rétention est généralement infinie. C'est rare les gens qui acceptent que leurs vieilles données soient purement et simplement inaccessibles => on garde tout, que ce soit les pages indexées par Google, les messages du forum, les photos/mp3 sur son PC, ...

    Le corolaire c'est que la volumétrie est en augmentation constante. D'ou le problème d'avoir des espaces de stockages de plus en plus gros (et donc ta remarque sur le prix des DD). Et finalement, la performance d'accès a ces grosses quantités de données.

    Et c'est la que, pour moi, il y a une différence entre SGBD et NoSQL :

    - Pour améliorer la performance accès/volumétrie d'un stockage SGBD, il faut modifier le SGBD (algos, architecture, schéma)

    - Pour améliorer la performance accès/volumétrie d'un stockage NoSql, il faut ajouter de nouvelles machines.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  11. #11
    Membre habitué
    Profil pro
    Inscrit en
    février 2006
    Messages
    139
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : février 2006
    Messages : 139
    Points : 152
    Points
    152

    Par défaut

    Bonsoir,
    Plus j'essaie de comprendre le NOSQL et moins je le comprends.
    En regardant de loin ( Memcached ) le but de redis ou memcached, je ne vois pas de quoi à casser 3 pattes à un canard. Memcached est .. un cache de données. La belle affaire. Les sgbd dignes de ce nom, Oracle par exemple, gère le cache avec des algorithmes pointus de LRU. Toujours pour Oracle, on trouve RAC(oracle cluster) où le cache est "partagé"(echangé) entre serveur ou bien TimesTen (Oracle in memory avec fusion de cache pour l'écriture). Pourtant, ces produits sont classés dans les SGBDR.
    Enfin l'exemple, toujours
    Memcached, me semble être simplement de la bonne pratique de développement: je crée très souvent des tableaux de données issues de requêtes SQL lorsque je dois accéder souvent aux mêmes informations. Cependant, lorsque l'on a mis "trop" de données en cache sous forme de tableaux/hashmap, on est obligé de faire des boucles, des if pour rechercher la donnée pertinente. Il arrive un seuil où il est préférable(= plus performant) de demander au SGBD de nous trouver lui même nos données, avec ses propres algorithmes optimisés et...avec une bonne vieille requête SQL.

    Bon cela dit, les Hashmap ne sont qu'un type de NOSQL, je vais essayer de comprendre les autres.

  12. #12
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 017
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 017
    Points : 16 017
    Points
    16 017

    Par défaut

    Citation Envoyé par kervoaz Voir le message
    Bonsoir,
    plus j'essaie de comprendre le NOSQL et moins je le comprends.
    En regardant de loin(wikipedia) le but de redis ou memcached, je ne vois pas de quoi à casser 3 pattes à un canard. Memcached est .. un cache de données. La belle affaire. Les sgbd dignes de ce nom, Oracle par exemple, gère le cache avec des algo pointus de LRU. Toujours pour Oracle, on trouve RAC(oracle cluster) où le cache est "partagé"(echangé) entre serveur ou bien TimesTen(Oracle in memory avec fusion de cache pour l'écriture). Pourtant ces produits sont classés dans les SGBDR.
    Memcached's APIs provide a giant hash table distributed across multiple machines.

    Le mot "distribué" est important. A ne pas confondre avec "partagé/échangé".

    Distribué signifie que chaque machine contient UNE PARTIE seulement des données (parfois en doublon avec une autre machine). Et que l'algorithme d'accès au cache permet de trouver les données, sans pour autant avoir besoin d'avori la liste exhaustive des machines et des clés présentes sur ces machines.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  13. #13
    Membre du Club
    Inscrit en
    juin 2008
    Messages
    43
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 43
    Points : 65
    Points
    65

    Par défaut

    Moi je ne comprend pas trop en quoi le NoSql dérange.
    On a bien plusieurs paradigme de programmation, encore plus de langages
    Je rejoins donc les quelques avis précédant en disant que SQL est peut-être génial mais que ça n'empêche pas d'aller voir ailleurs ce qui se passe.
    C'est un peu comme ça qu'on avance.
    Au niveau des entreprises je ne vois pas en quoi NoSql ou tout autres façons d'aborder les données serait un risque.
    Après tout si l'entreprise n'a pas assez de compétence dans ses rangs pour discerner les effets de modes des vraies solutions qui valent le coup ils finiront par se casser les dents un jour ou l'autre alors que ce soit sur ça ou sur autres choses le résultat ne sera pas forcément très différent.

  14. #14
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    2010, où l'informatique découvre que depuis qu'elle existe, la donnée n'a pas fait l'objet exclusif d'une base de donnée relationnelle implémentant SQL.




    Ça devient un grand nawak cette société de buzz.

    Lire ce genre de truc sur le noSql, ça me fait l'effet d'une polémique sur Eric Zemmour : C'est tellement provocateur qu'on sent que c'est écrit pour seulement faire parler de l'auteur.

    Mais les tautologies sur la mode est passagére (ouh ouh!), la migration entraine des effets de bords (ah ah!) et un développeur a une tendance a vouloir utiliser les technologies les plus récentes (eh eh!)...C'est un peu vide de contenu.

  15. #15
    Membre confirmé
    Inscrit en
    octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : octobre 2007
    Messages : 210
    Points : 450
    Points
    450

    Par défaut

    Je crois d'avantage aux bases de données produisant des résultats en XML.

    Le tout objet n'a pas d'avenir pour les bases de données, tout simplement parce que dans 95% des cas les données extraites doivent être resérialisées dans un autre format (HTML, XML, PDF, etc...). Dans le cas d'une extraction de donnée, l'objet devient donc un intermédiaire contraignant.

    Avec un peu de recul on se rend compte que les technologies OXM comme Hibernate, sont une réponse à une problématique mal formulée, surtout en ce qui concerne le Web. Avec la démocratisation d'ajax, de plus en plus de données sont transmises en XML, ce qui oblige les développeurs à utiliser deux technologie : Hibernate + JAXB/Json. On peut facilement virer les deux et remplacer par une base XML.

  16. #16
    Membre chevronné
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 167
    Points
    2 167

    Par défaut

    C'est vrai, mais XML, c'est massif et lourd. Ça ne conviendra pas à tous les usages.

  17. #17
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2006
    Messages
    572
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : septembre 2006
    Messages : 572
    Points : 623
    Points
    623

    Par défaut

    Là où tout le monde se plante, c'est que NoSQL n'est pas le remplaçant de SQL mais le complément (NOSql = Not Only SQL).

    D'abord, avant que vous n'ayez à vous poser la question de "oh, mon cluster de mysql comment à devenir compliquer à scaler horizontalement", vous avez de la marge. Seul les plus gros connaissent ce problème et ont dû trouver une solution.

    Ensuite, la plupart de ces sites ont une partie de leurs bases en sql et d'autres dans différentes configurations. Facebook utilise HBase (de hadoop) pour ses logs et ses statistiques !

    Evidemment, certains sont allé plus loin, comme Digg qui a remplacé sa base principale par Cassandra. Mais la grande majorité utilise un mélange des deux mondes.

    Voila quelques liens pour vous aider à mieux voir le truc :
    Les boites qui utilisent HBase, comment et pourquoi
    Un exemple plus précis de pourquoi et comment Adobe utilise HBase (et le reste des produits hadoop, c'est dont la HStack)
    Digg utilise Cassandra

    Enfin, une série d'article pour comprendre comment marche Cassandra, c'est la stack NoSQL la plus avancée actuellement

    Voila
    Venez partager vos expériences au sein d'un projet sur slicesofit, agile & amélioration continue

  18. #18
    Membre confirmé Avatar de saad.hessane
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2008
    Messages
    315
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2008
    Messages : 315
    Points : 499
    Points
    499

    Par défaut

    Citation Envoyé par hgomez Voir le message
    Je me rappelle d'une époque pas si lointaine où le stockage et la persistance n'utilisait pas des SGBR. Et je ne parle pas d'applications personnelles en environnements pré-web 1.0, mais de solutions professionnelles utilisées par exemple dans des environnements financiers (boursier ou banquaire).
    Cela est toujours le cas quand il faut maintenir une application vieille de 10 ans en COBOL, qui marche à merveille et qui n'utilise que des fichiers plats.

  19. #19
    Membre confirmé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    avril 2009
    Messages
    819
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : avril 2009
    Messages : 819
    Points : 595
    Points
    595

    Par défaut ok

    je pense qu'avant d'envisager de passer à nosql pour un souci de performance, il faut déjà passer de mysql à postgres, et de postgres à oracle/MS server et seulement en dernier recours abandonner le sql pour NoSQL.

    C'est par parce que mysql ne tient pas la charge que les autres sgbrs ne le peuvent pas.

  20. #20
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 048
    Points : 1 617
    Points
    1 617

    Par défaut

    Je trouve quand même incroyable que certains pensent encore et toujours que SQL (et les bases de données relationnelles) seront la solution ultime de manière éternelle.
    Il existe des domaines où ce n'est pas la panacée, et il existe des solutions bien plus performantes, n'en déplaisent aux fanatiques : déjà citée, la gestion de documents notamment. Pour autant, ces alternatives spécifiques à des métiers seront-elles généralisées ? Non SQL, ne disparaitra pas de sitôt, et oui, de nouvelles solutions vont continuer d'émerger. Et c'est tant mieux.
    Je termine par le "buzz" NoSQL : le nom est volontairement provocateur, pour mettre en lumière le fait qu'il existe d'autres solutions, et cela permet aux gens de se poser des questions. Se remettre en cause, chercher des solutions optimales à nos problèmes, n'est-ce pas là une de nos compétence ?
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

Discussions similaires

  1. Réponses: 72
    Dernier message: 05/02/2011, 18h16
  2. Réponses: 6
    Dernier message: 24/03/2010, 19h36
  3. Réponses: 20
    Dernier message: 16/11/2009, 23h04
  4. Réponses: 2
    Dernier message: 10/12/2008, 10h53
  5. Réponses: 16
    Dernier message: 10/06/2008, 08h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo