+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités
    Avatar de Coriolan
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2016
    Messages
    417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Maroc

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2016
    Messages : 417
    Points : 10 219
    Points
    10 219

    Par défaut Une nouvelle étude montre la montée en puissance du NoSQL

    Une nouvelle étude montre la montée en puissance du NoSQL
    Avec de plus en plus d'entreprises qui se tournent vers le cloud public

    La NoSQL désigne une famille de systèmes de gestion de bases de données (SGBD) qui s’écarte du paradigme classique des bases relationnelles. À partir des années 2000, les grandes entreprises du web ont été amenées à traiter des volumes de données très importants, une tâche non adaptée au modèle relationnel qui souffre de plusieurs limitations liées au fait qu’il a été conçu pour fonctionner sur des ordinateurs uniques. Afin de répondre à ces limites, ces entreprises ont commencé à développer de nouvelles solutions de gestion de bases de données pouvant fonctionner sur des architectures matérielles distribuées et permettant de traiter des volumes de données importants. Ces nouveaux systèmes NoSQL sont dotés de performances qui restent bonnes avec la montée en charge (scalabilité) en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse de coûts.

    Aujourd’hui, les bases de données NoSQL sont devenues incontournables, avec de plus en plus d’entreprises qui se tournent vers ces solutions. Selon le rapport Forrester Wave for Big Data NoSQL, Q3 2016, « le NoSQL n’est plus une option, c’est une nécessité pour les applications de nouvelle génération ». Les décideurs (de plusieurs pays, dont la France) ont réalisé le potentiel que présente le NoSQL. L’enquête de Forrester a révélé que 29 % des interrogés ont déclaré avoir déjà implémenté ou sont en train d’implémenter la technologie NoSQL; 12 % sont en train d’élargir ou mettre à niveau leurs implémentations. Les entreprises sont attirées par le modèle NoSQL qui permet le traitement d’énormes quantités de données, la structuration relationnelle faible et la capacité d’accès très rapide, quitte à multiplier les serveurs.

    Nom : plans.jpg
Affichages : 6467
Taille : 29,7 Ko
    61 % des entreprises interrogées par Forrester ont déjà implémenté une base de données NoSQL ou prévoient de le faire à court terme

    Il n’est plus question aujourd’hui de savoir si les entreprises vont adopter le NoSQL, 61 % des entreprises interrogées par Forrester ont déjà implémenté une base de données NoSQL ou prévoient de le faire à court terme. Aujourd’hui, on se demande plutôt si les entreprises vont se contenter de leurs propres serveurs ou se tourner vers le cloud public.

    Nom : challengers.jpg
Affichages : 5246
Taille : 50,6 Ko
    Classement des différentes SGBD NoSQL sur le marché

    Pour le classement des bases de données NoSQL, MongoDB reste le leader et la solution open source la plus populaire. Cette base de données NoSQL orientée-document tire sa popularité de sa facilité et sa capacité de supporter la montée en charge des applications les plus exigeantes. La solution NoSQL Cloud propriétaire DynamoDb est aussi bien classée. Utilisable essentiellement via AWS, cette solution est exploitée par les entreprises pour un large éventail de tâches, comme les campagnes de publicité, les applications de médias sociaux et la collecte et l’analyse de données… Bien que Microsoft a eu un certain retard sur ce marché, sa solution Azure DocumentDB a connu une forte croissance depuis son lancement.

    Selon les chiffres avancés par le cabinet d’études Gartner, le nombre de machines virtuelles (VMs) du cloud public a été multiplié par 20 en trois ans (entre 2011 et 2014 ) alors que les VM du cloud privé ont été multipliées par 3, une performance liée au fait que le cloud public permet une scalabilité horizontale adaptée aux nouveaux besoins du marché. Le cloud public favorise une agilité accrue qui permet aux entreprises de se concentrer sur l’amélioration de leurs services et laisser aux opérateurs du cloud la tâche de gérer leur infrastructure. Selon Gartner, d’ici 2020, 10 % de part du marché de systèmes de bases de données va être conquise par des solutions de cloud public, ce qui ne peut que renforcer le statut du NoSQL comme la solution de choix pour les applications de nouvelle génération.

    Source : Forrester - Gartner

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi :

    Forum NoSQL

  2. #2
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 198
    Points : 2 633
    Points
    2 633

    Par défaut

    Citation Envoyé par Coriolan Voir le message
    Qu'en pensez-vous ?
    Je pense que 90% des projets sont totalement a coté de la plaque et il n'y avait aucun besoin de NoSql pour les traiter.
    Seulement beaucoup de monde veut se donner l'impression de faire des choses impressionnantes comme les gros...Sauf qu' il y a peu d'entreprise qui gère le peta-(voire exa-)octet.
    Par exemple sur ce fil http://www.developpez.net/forums/d15...nnees-l-insee/ , on a un besoin impressionnant sur de la big data. Rendez vous compte un fichier zip de 33mo! Bon là le gars va surement s'en sortir sans devoir trop investir en infra, mais si le fichier monte a 50Mo là je pense qu'il faudra serieusement envisager le cloud pour les monter en charges...

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 440
    Points : 0
    Points
    0

    Par défaut

    Je pense que 90% des projets sont totalement a coté de la plaque et il n'y avait aucun besoin de NoSql pour les traiter
    Le seul avantage du NoSql n'est pas les performances. Dans beaucoup (la plupart) des projets il n'est pas nécessaire du point de vue performance.

    Mais dans la facilité et l'architecture des applications ça apporte un plus. Il n'y a plus besoin de mapper le Domain Model vers le Data Model. Donc simplification. On sauve le Domain Model directement. Ce qui force les developpeurs a adopter le DDD et a créer des 'Boundaries' fortes. Ce qui permet de faire du Microservice et donc d'en avoir les avantages.

    Mais ça engendre d'autre problématiques quand on change le DomainModel (Migration du schéma...)

    Et il ne faut pas se mentir.. quand on peut se passer des DBA pour le tuning et toute les contraintes c'est tentant..

  4. #4
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 198
    Points : 2 633
    Points
    2 633

    Par défaut

    Citation Envoyé par Aeson Voir le message
    Il n'y a plus besoin de mapper le Domain Model vers le Data Model. Donc simplification. On sauve le Domain Model directement.
    ...
    Mais ça engendre d'autre problématiques quand on change le DomainModel (Migration du schéma...)
    A voir sur la durée, effectivement on gagne lors de la phase initial mais sur le long terme j'en suis pas certains. Si l'on est aller mettre une donnée au fin fond d'une hiérarchie parceque ca semblait accessoire lors de la conception ça va être délicat a faire remonter.
    Sinon pour ce qui est de se passer de DBA, j'en ai tellement rarement vu que je serais bien content d'en avoir un de temps à autres (je déteste le SQL...)! En vrai je préfère l'approche NoSql mais plus par feneantise que par réel besoin. Un peu comme les ORM, normalement ca nécessite pas mal de boulot pour etre sûr de pas faire de la merde, mais en vrai on s'en sert surtout pour s'eviter la tache bien chiante de l'ecriture de la DAL.

  5. #5
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 440
    Points : 0
    Points
    0

    Par défaut

    je déteste le SQL...
    Comme beaucoup... C'est un point fort du NoSql

    Pour les ORM c'est toujours du SQL derriere. D'ou le mapping vers le DataModel. Pouvoir se passer de ce mapping offre donc des avantages. Et comme le NoSql offre de très bonne performance vu sont architecture c'est tous bon..

    L'avantage des ORM c'est de masquer le SQL (avec du mapping). Le SQL generé faisait souvent bondir les DBA... Utiliser un ORM fait dans la plupart des cas perdre en performance. Mais comme c'est plus facile et que ca fait gagner du temps, ces pertes sont acceptées malgré les cris des DBA.

    Avec des store comme MongoDB on peut encore aller plus loin en gardant les performances, augmentant la productivité et en forcant une architecture DDD (avec tous ces avantages)

  6. #6
    Membre du Club
    Inscrit en
    novembre 2004
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 28
    Points : 69
    Points
    69

    Par défaut

    La mise à jour du schéma d'une base NoSQL est souvent plus simple qu'en SQL. Retour d'expérience :

    SQL : modifier un schéma en SQL (que l'on utilise un ORM ou pas) demande du travail, ne serait-ce que pour toucher à des FK, casser des contraintes, etc. Ce n'est pas pas évident à la base (et peut être, avouons-le, pas tellement pensé pour)

    NoSQL (MongoDB, Neo4j et Marklogic pour mon expérience personnelle) : modifier un schéma NoSQL est plus facile à mettre en œuvre car il y a beaucoup moins de contraintes. Pas de FK, pas de liens forts entre les données. On peut donc faire ce que l'on veut (aka "tout casser").
    La mise à jour du schéma se fait généralement en remodelant les données : on ajoute/retire/renomme/déplace facilement des champs. En fait il n'y a aucune contrainte (si ce n'est le temps d'exécuter l'upgrade des données) pour tout modifier.
    Dans la boite où je travaille on a l'habitude de maintenir des scripts de migration. Ces scripts sont lancés à chaque démarrage de l'appli. L'évo du modèle se fait donc en même temps que la livraison (et biensûr testée en intégration continue). Les partie obsolètes des scripts d'évo sont retirés quand on remarque qu'ils ne servent plus.
    Faire ça en SQL est plus prise de tête.

    La seule chose qui me manque quand je fais du NoSQL, c'est la puissance et la simplicité (toute relative, j'ai surtout commencé ma vie de dev par ça, ça aide) du langage ainsi que sa normalisation. Quasiment le même SQL sur MariaDB, Oracle, SQLServer... alors qu'en NoSQL non seulement les dialectes sont nouveaux, pas toujours très pratiques pour les requêtes complexes (en particulier MongoDB, les projections deviennent vite tordues), mais on presque a un dialecte par base NoSQL. Il n'y en a que 2~3 qui proposent soit un langage proche du SQL (le cas de Couchbase) ou un driver JDBC (ex avec Neo4j).

    Les pro-SQL diront sans doute que le SQL permet de bien verrouiller le modèle avec des contraintes, sécurité que l'on n'a pas en NoSQL (même si cette fonctionnalité commence à pointer le bout de son nez) ; mais finalement on s'en passe très bien. Du moment que le code métier est bien testé, tout roule.

    Bref, pour moi l'avenir de la donnée c'est du NoSQL (type document, graphe, keyvalue, etc selon les besoins) + du test-driven.

  7. #7
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 119
    Points : 2 637
    Points
    2 637
    Billets dans le blog
    12

    Par défaut

    je déteste le SQL...
    Quel que soit le domaine, on a souvent tendance à "détester" les choses que l'on ne maîtrise pas. Pour moi le SQL est le meilleur langage standardisé existant pour manipuler des données tabulaires, on aura beau utiliser des map/reduce, streams, LINQ ou autre, on n'arrive pas à la cheville de ce concept créé par des ingénieurs d'IBM en 1974.

    Les bases NoSQL c'est bien, surtout ceux qui ont une utilité bien précise telle que Redis pour le cache par exemple, mais pour une utilisation plus étendue, les bases NoSQL telle que MongoDB par exemple, je me pose des questions. Je suis conscient du fait que ces technos permettent de gagner en agilité (surtout pour les développeurs JavaScript/ Node.js), il est possible durant le développement de changer son modèle de donnée à la volée lorsque le client décide d'ajouter une feature sur un coup de tête, conclusion ça pète pas alors qu'avec une base relationnelle cela demande plus de délicatesse (on doit gérer le typage des colonnes etc je ne vous apprends rien)...

    Mais il y a beaucoup de concept que l'on châtre en utilisant ce type de techno, on veut créer un site e-commerce ? Ok, comment allons-nous gérer les transactions entre les traitements effectuées sur plusieurs documents à la fois ? On veut récupérer des données sans forcément dupliquer une infinité d'objets dans des objets, comment faire sans une simple jointure ? Comment réaliser des requêtes complexes avec une syntaxe JS alors qu'en SQL j'enchaine avec une simplicité hallucinante mon groupement, mes filtres, et mes fonctions d'agrégats ?
    Aujourd'hui ces technos sont cools, mais trop jeunes... Je vous prends un tout petit exemple d'un projet, avec MongoDB vous ne pouvez pas faire un "sort" correctement du fait que ce dernier ne sait pas gérer l'insensitive, alors que fait-t-on ? On bidouille, on crée un champ supplémentaire dont le contenu est en uppercase ou lowercase par exemple.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  8. #8
    Membre du Club
    Inscrit en
    novembre 2004
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 28
    Points : 69
    Points
    69

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Mais il y a beaucoup de concept que l'on châtre en utilisant ce type de techno, on veut créer un site e-commerce ? Ok, comment allons-nous gérer les transactions entre les traitements effectuées sur plusieurs documents à la fois ? On veut récupérer des données sans forcément dupliquer une infinité d'objets dans des objets, comment faire sans une simple jointure ? Comment réaliser des requêtes complexes avec une syntaxe JS alors qu'en SQL j'enchaine avec une simplicité hallucinante mon groupement, mes filtres, et mes fonctions d'agrégats ?
    Aujourd'hui ces technos sont cools, mais trop jeunes... Je vous prends un tout petit exemple d'un projet, avec MongoDB vous ne pouvez pas faire un "sort" correctement du fait que ce dernier ne sait pas gérer l'insensitive, alors que fait-t-on ? On bidouille, on crée un champ supplémentaire dont le contenu est en uppercase ou lowercase par exemple.
    Totalement vrai pour MongoDB. Si l'on veut faire de la recherche, on nous pousse très vite à passer par du elasticsearch :p
    Par contre je te recommande vivement Couchbase (le langage est très proche du SQL : jointures, etc, ainsi que de vraies transactions) et Marklogic, ce dernier étant très très fort pour la recherche (case sensitive, support ds langues, et plein de trucs très poussés) ; il est connu pour ça.

    MongoDB est peut être une des bases NoSQL les moins évoluées, mais hélas la plus en vogue.

  9. #9
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 440
    Points : 0
    Points
    0

    Par défaut

    On peut donc faire ce que l'on veut (aka "tout casser").
    Quand le changement de schema implique une migration de données, faire un script SQL et des migrations a deployer sur la DB est plus simple (a mon avis).

    Quel que soit le domaine, on a souvent tendance à "détester" les choses que l'on ne maîtrise pas
    Effectivement. Mais les développeurs veulent de l'orienté objet. D'ou le succes des ORM et de frameork comme Linq.

    on n'arrive pas à la cheville de ce concept créé par des ingénieurs d'IBM en 1974.
    Je ne penne pas. Manipuler des classe / objet est plus facile que de manipuler des tables et des row.

    Ok, comment allons-nous gérer les transactions entre les traitements effectuées sur plusieurs documents à la fois ?
    .Net gere tres bien les transactions et les acces concurentiel (lock) sont geré par MongDB. C'est une nouvelles faconde travailler donc ca demande du temp...

    Comment réaliser des requêtes complexes avec une syntaxe JS
    JavaScript.... Comme dirait Martin Fowler il est temps qu'on se débarrasse de ce langage... SURTOUT coté Backend... il n'a jamais ete fait pour ca. Alors acceder a une DB en JavaScript...

    SQL j'enchaine avec une simplicité hallucinante mon groupement, mes filtres, et mes fonctions d'agrégats ?
    c# est tres puissant pour travailler sur les collections (je suppose que Java aussi). Ce ne sont pas des tables mais des objets. Donc un langage objet y a tout a fait sa place d'apres moi.

    que ce dernier ne sait pas gérer l'insensitive,
    Je suppose que tu parle de 'Case Sensitive' ? Une solution est d'utiliser RegEx...

  10. #10
    Expert Oracle confirmé

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2003
    Messages
    335
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : mars 2003
    Messages : 335
    Points : 638
    Points
    638

    Par défaut

    Bonjour,

    Les besoins des entreprises évoluent, et par voie de conséquence les solutions logicielles aptes à répondre à ces nouveaux besoins aussi.

    Débutant en Big Data et en NoSQL, j'essaye d'allier le meilleur des 2 mondes (entre les SGBDR et les bases NoSQL), et pour cela j'ai besoin de comprendre les fondamentaux de chaque type de technologies.

    Le but est de me constituer ainsi une sorte de catalogue de services, catalogue où je pourrais ainsi piocher le bon outil en fonction de mes besoins du moment.



    Je vous donne un exemple très concret et qui est à l'origine de mon tout premier Use-Case en entreprise.

    J'ai comme chaque année un audit à réaliser sur BO (Business Objects). Je dispose donc d'une extraction au format CSV des groupes d'utilisateurs, et des utilisateurs.

    Jusqu'à présent, je réinjectais ces données dans une base de type SGBDR (Oracle dans mon cas). Comme les groupes d'utilisateurs sont des données hiérarchiques, le SQL était parfait pour répondre à mes interrogations via des requêtes hiérarchiques (START WITH .... CONNECT BY ....)

    Par contre, c'est une autre paire de manches pour les utilisateurs qui ne sont plus organisés en hiérarchie (un utilisateur pouvant être rattaché à plusieurs groupes).


    Du coup, pour cette année, j'ai innové en injectant mes données dans une base de données NoSQL orientée graphes (Neo4j dans mon cas).

    N'ayant aucun volume (juste 153 groupes et 1128 utilisateurs), ce type de base est cependant beaucoup plus apte à répondre à mes besoins que le traditionnel SGBDR.

    Pour moi, il n'y a pas d'outils ou de technologies meilleures que d'autres. Parmi toute cette (riche) palette, il faut choisir si possible ce qui est le mieux adapté à ses besoins propres.

    Comme toute chose, cela demande bien sur du temps, beaucoup de temps :
    - comprendre les principes et mécanismes de base
    - s'approprier l'outil, notamment au niveau de l'ingestion des données (quels sont les outils pour importer ces données), et surtout l'interrogation des données.

    Il y a 20 ans de cela, j'ai appris le langage SQL. Là j'ai du réapprendre le langage Cypher utilisé dans ce type de base.

    Et si je passe à une base NoSQL orientée document, ce sera encore un langage différent.

  11. #11
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 440
    Points : 0
    Points
    0

    Par défaut

    il y a aussi SPARQL pour le BIG data.. Cypher est un language proprietaire.

    Dans ce cas si on est dans des documents RDF et des TrpletStore... plus sur des techno du style MongpDB. A mon avis ce sont 2 choses differentes

  12. #12
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 203
    Points : 683
    Points
    683

    Par défaut

    Je risque d'aller à contre-sens de la plupart des interventions sur ce thread, on verra bien comment le débat évoluera :p

    Bon tout d'abord, je n'ai jamais eu à gérer de vraiment grosses bases de données (max 2 tera, pour une base de données qui faisait de la traduction), donc le big data ne me parle pas trop ...

    Par contre, j'aimerais réagir au fait que même pour des petites bases de données, le nosql est pratique puisqu'il simplifie les choses.

    J'ai développé mes derniers projets de la manière suivante :

    - La base de données gère les données;
    - Le code "métier" s'occupe de l'interface utilisateur.

    Je trouve cela particulièrement efficace pour la gestion des droits : Je peux fournir à l'utilisateur un accès direct au client en ligne de commande de la base de données; je suis certain qu'il ne pourra rien faire de plus que ce que j'ai décidé de l'autoriser à faire.

    Lorsqu'une erreur est renvoyée (par exemple la contrainte CHECK_MESSAGE_NON_EMPTY est violée lors de l'insertion), il me suffit d'afficher le message d'erreur (i18n par exemple) correspondant.

    J'aime bien cette manière de travailler, je l'utilise sur 3 petits projets personnels et je compte continuer tant que je n'y trouve pas de défaut majeur.

    Je pense qu'il est possible d'adapter cette méthodologie à de petites équipes de développement. Par contre je ne pense pas qu'elle soit viable pour de gros projets (à moins d'avoir autant de DBA que de développeurs )

    Je suis ouvert à toute remarque : trouvez-vous cela finalement plus compliqué qu'une DB qui se limite à l'aspect stockage ? Êtes-vous contre l'idée d'implémenter la moindre logique dans la DB ?

  13. #13
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 198
    Points : 2 633
    Points
    2 633

    Par défaut

    Citation Envoyé par Shepard Voir le message
    Êtes-vous contre l'idée d'implémenter la moindre logique dans la DB ?
    J'ai jamais aimé les SI avec une partie seulement qui était sous forme de procédure stockée. Soit on mets aucune logique soit on mets tout, or souvent c'est un peu anarchique.
    Mais bon c'est plus une question d'organisation qu'autre chose.

  14. #14
    Modérateur
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    mars 2004
    Messages
    4 246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : mars 2004
    Messages : 4 246
    Points : 10 423
    Points
    10 423

    Par défaut

    Citation Envoyé par micka132 Voir le message
    J'ai jamais aimé les SI avec une partie seulement qui était sous forme de procédure stockée. Soit on mets aucune logique soit on mets tout
    Non, pas forcément. L'extrémisme n'est jamais bon. J'ai bien plus souvent vu des système où ce qui aiguillait le choix entre procédure stockée et routine externe était uniquement le temps de traitement. J'ai travaillé pour des clients qui avaient des règles strictes du genre : si le temps de réponse à une requête dépassait par exemple 600 millisecondes -> tu passais en mode spéléo. Et bien souvent le traitement finissait déporté en procédure stockée.
    # Dans la Création, tout est permis mais tout n'est pas utile...

  15. #15
    Candidat au Club
    Homme Profil pro
    Analyste Développeur Java
    Inscrit en
    mars 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste Développeur Java

    Informations forums :
    Inscription : mars 2013
    Messages : 1
    Points : 3
    Points
    3

    Par défaut

    Bonjour,


    Pour ma part, je regarde fortement vers le NoSQL, dans cette myriade de base de données, un qui sort du lot étant OrientDB (certes il est jeune), au vu de ce qu'il offre déjà maintenant c'est un grand pas en avant.

    1) Gestion des Groupes-Users et permissions jusqu'à un niveau bas.
    2) Multi-Model (Key-Values; Documents; Graph)
    3) Master-Master (réplication)
    Et je ne cite que les 3 premiers que j'ai en tête.

    ne me parlez pas de MongoDB ou l'on perd la notion de "relation" ce qui est normal puisque ce n'est qu'une base de données Documents et donc si relation il y a au niveau business il faut la coder dans l'application.
    ne me parlez pas de Neo4J ou aucune gestion de permission n'est possible, et ou les requêtes sont très différentes de part le fait que c'est du graph uniquement..

    Pourquoi chercher une db qui ne fait qu'un type de structuration data, alors qu'on peut avoir le meilleur de toute la famille NoSQL ??? je confirme avoir un oeil sur l'évolution d'OrientDB.

    bàv

  16. #16
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 381
    Points : 6 903
    Points
    6 903

    Par défaut

    Citation Envoyé par Aeson Voir le message
    Effectivement. Mais les développeurs veulent de l'orienté objet. D'ou le succes des ORM et de frameork comme Linq.
    Les mauvais développeurs veulent de l'orienté objet, les autres apprennent le SQL. Je trouve pour ma part tous les ORM que j'ai pu tester / pratiquer imbouffables dès qu'il s'agit de faire autre chose qu'un select sur une table by id.

    Le SQL est un outil, comme les langages orientés objets. Le SQL est designé pour traiter avec des données tabulaires, pas l'orienté objet.

    Je me désolé de voir les horreurs écrites en java ou c# dans les couches DAO simplement parce que le développeur qui a écrit ce code n'a pas pris 1 journée pour se former au SQL (c'est hyper simple comme langage).
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  17. #17
    Membre chevronné
    Avatar de SurferIX
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 792
    Points : 1 827
    Points
    1 827

    Par défaut

    Citation Envoyé par Aeson Voir le message
    Le seul avantage du NoSql n'est pas les performances. Dans beaucoup (la plupart) des projets il n'est pas nécessaire du point de vue performance.

    Mais dans la facilité et l'architecture des applications ça apporte un plus. Il n'y a plus besoin de mapper le Domain Model vers le Data Model. Donc simplification. On sauve le Domain Model directement. Ce qui force les developpeurs a adopter le DDD et a créer des 'Boundaries' fortes. Ce qui permet de faire du Microservice et donc d'en avoir les avantages.

    Mais ça engendre d'autre problématiques quand on change le DomainModel (Migration du schéma...)

    Et il ne faut pas se mentir.. quand on peut se passer des DBA pour le tuning et toute les contraintes c'est tentant..
    Cherche juste "is mongodb safe". Tu verras.
    De plus comme le dit Mika132 juste après ton post, c'est bien pour démarrer à l'arrache, mais c'est totalement ingérable très rapidement.

    Et tu en arrive à l'image qui parle le mieux au monde :

    "Sets of sets of sets of sets. Tasty fractals."
    Nom : Cauliflower_Fractal_AVM-1024x687.jpg
Affichages : 104
Taille : 148,8 Ko
    "Ceci dit" n'est pas correct. Cf Wikipedia. Cela dit est du français correct.
    Je suis parfois... ⇛ ☆★ En direct ★☆

  18. #18
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 871
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 871
    Points : 39 165
    Points
    39 165

    Par défaut

    Citation Envoyé par Coriolan Voir le message
    La NoSQL désigne une famille de systèmes de gestion de bases de données (SGBD) qui s’écarte du paradigme classique des bases relationnelles. [.... Le] modèle relationnel qui souffre de plusieurs limitations liées au fait qu’il a été conçu pour fonctionner sur des ordinateurs uniques.
    Ceci est faux... Les bases de données relationnelles sont aujourd'hui et depuis longtemps capable de dispatcher les données sur différentes nœuds. Si je prend l'exemple de SQL Server il existe des mécanismes de partitionnement et de fédération (DPV, service broker ... par exemple) tout à fait capable de "spliter" une même base sur plusieurs serveurs. Un exemple est PANN STARS. Autre exemple en France FNAC.COM.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  19. #19
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 871
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 871
    Points : 39 165
    Points
    39 165

    Par défaut

    Citation Envoyé par rouardg Voir le message
    Jusqu'à présent, je réinjectais ces données dans une base de type SGBDR (Oracle dans mon cas). Comme les groupes d'utilisateurs sont des données hiérarchiques, le SQL était parfait pour répondre à mes interrogations via des requêtes hiérarchiques (START WITH .... CONNECT BY ....)
    Par contre, c'est une autre paire de manches pour les utilisateurs qui ne sont plus organisés en hiérarchie (un utilisateur pouvant être rattaché à plusieurs groupes).
    Malheureusement vous utilisez Oracle qui depuis des décennies refuse de se conformer aux normes SQL qui permettent justement des parcours de graphe via le concept de CTE récursives.... Il est probable qu'avec un SGBDR respectueux des normes comme SQL Server ou PostGreSQL votre problème aurait été traité avec beaucoup plus de performances et via une requête plus élégante et très facile à mettre en œuvre !


    Du coup, pour cette année, j'ai innové en injectant mes données dans une base de données NoSQL orientée graphes (Neo4j dans mon cas).

    N'ayant aucun volume (juste 153 groupes et 1128 utilisateurs), ce type de base est cependant beaucoup plus apte à répondre à mes besoins que le traditionnel SGBDR.

    Pour moi, il n'y a pas d'outils ou de technologies meilleures que d'autres. Parmi toute cette (riche) palette, il faut choisir si possible ce qui est le mieux adapté à ses besoins propres.
    On est bien d'accord... Encore faut-il bien connaître les outils !

    Comme toute chose, cela demande bien sur du temps, beaucoup de temps :
    - comprendre les principes et mécanismes de base
    - s'approprier l'outil, notamment au niveau de l'ingestion des données (quels sont les outils pour importer ces données), et surtout l'interrogation des données.

    Il y a 20 ans de cela, j'ai appris le langage SQL.
    Hélas mal... Prbabelemnt celui d'Oracle et ses limites... !

    Là j'ai du réapprendre le langage Cypher utilisé dans ce type de base.

    Et si je passe à une base NoSQL orientée document, ce sera encore un langage différent.
    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Discussions similaires

  1. Réponses: 29
    Dernier message: 27/12/2016, 12h28
  2. Réponses: 0
    Dernier message: 23/06/2014, 03h25
  3. Réponses: 187
    Dernier message: 08/09/2011, 09h28
  4. Réponses: 0
    Dernier message: 06/06/2011, 12h47
  5. Réponses: 5
    Dernier message: 26/08/2009, 01h09

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