Navigation

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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2018
    Messages
    249
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2018
    Messages : 249
    Points : 8 986
    Points
    8 986

    Par défaut Amazon envisage d'abandonner complètement les SGBD et services d’Oracle d’ici 2020

    Amazon envisage d'abandonner complètement les SGBD et services d’Oracle d’ici 2020
    Oracle serait incapable de répondre à ses besoins de performance

    Pour rappel, Oracle a enregistré déjà des départs de clients à cause de ses tactiques de vente agressives, menaçant les clients de ses logiciels sur site avec des audits d'utilisation potentiellement coûteux et proposant fortement la migration vers sa solution cloud comme une panacée à leurs problèmes. Par ailleurs, d’après les résultats d’une étude réalisée en avril par Jefferies & Company, Oracle s’est fait surclasser sur le marché des infrastructures et plateformes en tant que services (IaaS / PaaS) par Amazon, le leader du marché du cloud, Microsoft et autres. L’annonce de JP Morgan du mois de juin dernier selon laquelle Oracle serait en train de perdre la faveur des acheteurs de technologies pour des principaux fournisseurs de solutions de cloud computing participe à ce que l’on pourrait qualifier de chute de la société de Redwood Shores.

    Oracle serait devenu l’un des rivaux d’Amazon, le leader du marché du cloud computing, à cause de ses prouesses en la matière, selon CNBC. Amazon prévoit, par ailleurs, abandonner complètement les logiciels d’Oracle d’ici 2020. La raison principale serait l'incapacité de la technologie de base de données à évoluer pour répondre aux besoins de performances d'Amazon, selon une personne qui a connaissance du dossier. Le plan de retrait intervient aussi dans un contexte où la plupart des infrastructures ont été transférées en interne à Amazon Web Services. La séparation d’avec Oracle serait effective en mi-2019, a déclaré une autre source, qui selon elle, il n’y existerait pas de développement récent de nouvelles technologies basées sur Oracle.

    Nom : 101877184-jeff-bezos.530x298.jpg
Affichages : 6029
Taille : 17,0 Ko

    Pour cette raison, Amazon qui avait déjà commencé à déployer ses propres infrastructures en interne, envisage de se séparer complètement de son fournisseur de longue date en base de données sur site, Oracle, d'ici 2020. Ce probable arrêt est un signe de maturité de plus que laisse voir le géant du commerce électronique à ces concurrents. En effet, son fournisseur Oracle ne s’adapterait plus à ses besoins de performance de migration de ses charges vers le cloud abandonnant les solutions sur site d’Oracle.

    Amazon doit cette performance à l'expansion d'Amazon Web Services qui lui a, par ailleurs, permis de surclasser Alphabet en début d’année pour devenir la deuxième entreprise cotée en bourse la plus importante au monde. Au second trimestre de cette année, AWS a enregistré une croissance de 49 %. Tandis que les résultats d’Oracle stagnent et les actions continuent de chuter.

    Selon l’une des sources, il y a 4 ou 5 ans qu’Amazon a commencé sa migration. Néanmoins, une partie de ses activités de base est toujours hébergée sur Oracle le temps de mener à bien la transition vers ses propres infrastructures. Selon une source d’information, la migration complète interviendrait dans environ 14 à 20 mois.

    Toutefois, l’infrastructure d’Amazon n’est pas sans reproche. Une panne d'un programme interne appelé Sable, utilisé par Amazon pour fournir des services de stockage à ses entreprises de détail et numériques a entrainé de nombreuses erreurs lorsque les clients essayaient d’accéder au site lors du Prime Day d'Amazon, le mois dernier, selon CNBC.

    A propos des efforts fournis par Amazon pour son autonomie complète, Larry Ellison, président exécutif et directeur technique d'Oracle Corporation objecte en déclarant : « Laissez-moi vous dire qui ne quitte pas Oracle », a déclaré Ellison. « Une société dont vous avez entendu parler nous a donné ce trimestre 50 millions de dollars supplémentaires pour acheter une base de données Oracle et d’autres technologies Oracle. Cette société est Amazon. », a-t-il ajouté, infirmant ainsi les déclarations selon lesquelles Amazon s’apprêterait à se séparer d’avec les solutions Oracle. Ellison a poursuivi, par ailleurs, en soulignant que « les concurrents, qui n’ont aucune raison de nous aimer beaucoup, continuent d’investir et de gérer l’ensemble de leurs activités sur Oracle ».

    Les dirigeants d’Amazon continueraient d’investir dans la technologie d’Oracle selon un communiqué d’un porte-parole d’Oracle. Selon Oracle, Amazon ne serait pas prêt pour que ses gros clients puissent migrer vers sa plateforme.

    Amazon a réagi aux attaques de son fournisseur de base de données sur site pour défendre son infrastructure. Ses dirigeants ont loué, en 2017, les avantages de coût de l'utilisation du logiciel de base de données d’Amazon. Dans une riposte, le PDG d'AWS, Andy Jassy, a affirmé qu'Oracle était « très loin dans le cloud ».

    Cette guerre des mots a commencé avec le lancement d’Aurora, le service de base de données relationnelle d’Amazon ainsi qu’un outil permettant aux entreprises de déplacer des bases de données vers le cloud qui visent le marché d’Oracle et qui attitreraient déjà certains de ses clients.

    Cette guerre pourra durer encore longtemps, cependant depuis lors, Oracle n'a pas réussi à conquérir des parts de marché notables dans l'infrastructure cloud. AWS est en tête sur ce marché et est suivie par Microsoft, Google, Alibaba et IBM.

    Source : CNBC

    Et vous ?

    Qu’en pensez-vous ?
    Amazon est-il prêt pour son autonomie vis-à-vis de son fournisseur Oracle ?

    Voir aussi

    Les clients d'Oracle seraient en train de migrer vers SQL Server et d'autres SGBD, Oracle perdrait du terrain sur tous les fronts selon des analystes
    Les techniques de vente agressives d'Oracle s'avèrent contre-productives, elles ont tendance à chasser certains clients
    Gartner : Le marché des logiciels d'infrastructures et middleware en croissance en 2017, IBM en tête suivi par Oracle et Salesforce
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 835
    Points
    13 835

    Par défaut

    ce qu'il faut en penser ?
    moua ha ha je me marre je me marre...
    les entreprises qui ont basé leurs système d'information sur cette solution technologique si elles choisissent de changer de techno (indépendamment de l'éditeur Oracle) eh bien le risque c'est de devoir refaire les projets info de A à Z donc ça fera du boulot pour les programmeurs mais une charge pour les entreprises.

    On ne le répètera jamais assez mais dans un projet informatique et dans les lignes de code faites le plus abstrait possible en scindant le code en modules,entités qui ne soient pas dépendantes d'une techno en particulier ( ici Oracle)
    Car si vous changez de techno ici un SGBDR là faut réecrire une bonne partie du code
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  3. #3
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 498
    Points
    7 498

    Par défaut

    Citation Envoyé par Stan Adkens Voir le message
    Qu’en pensez-vous ?
    Travailler avec de gros éditeurs et tjrs une galère.
    J'ai été en relation avec MS, SAP, Salesforce, Amazon, IBM et Oracle et le pire de tous est Oracle.
    Ils sont d'une arrogance et d'une agressivité que je n'ai jamais vu ailleurs.
    Tout est bon pour nous faire raquer et dans des proportions démesurées.

    Côté SGBD, ça fait des années que tous les nouveaux projets auquel j'ai participé se font sous Pg et je participe de plus en plus à des projets de migrations d'Oracle vers Postgres.
    Rien qu'avec les économies de licences, les ROI de ces projets de migrations sont phénoménaux.

    Citation Envoyé par Stan Adkens Voir le message
    Amazon est-il prêt pour son autonomie vis-à-vis de son fournisseur Oracle ?
    Pas encore mais ça viendra
    Amazon a les ressources pour y parvenir et ne l'a jamais caché.

  4. #4
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 246
    Points : 1 059
    Points
    1 059

    Par défaut

    Citation Envoyé par Mat.M Voir le message
    ce qu'il faut en penser ?
    moua ha ha je me marre je me marre...
    les entreprises qui ont basé leurs système d'information sur cette solution technologique si elles choisissent de changer de techno (indépendamment de l'éditeur Oracle) eh bien le risque c'est de devoir refaire les projets info de A à Z donc ça fera du boulot pour les programmeurs mais une charge pour les entreprises.
    Refaire le projet de A à Z? Rien que cela?

    Pour info, les "SGBD Oracle", ce n'est rien d'autre que de la base de données SQL! A part de rares exceptions où il serait fait appel à des concepts très exotiques propres à Oracle, le remplacement d'une "SGBD Oracle" par une autre solution de base de données SQL se fait sans problème et surtout en refaisant le projet de la lettre A à ... La lettre B! Pas besoin de passer en revue les 26 lettres de l'alphabet

  5. #5
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 246
    Points : 1 059
    Points
    1 059

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Côté SGBD, ça fait des années que tous les nouveaux projets auquel j'ai participé se font sous Pg et je participe de plus en plus à des projets de migrations d'Oracle vers Postgres.
    Rien qu'avec les économies de licences, les ROI de ces projets de migrations sont phénoménaux.
    Idem...

    Oracle prend depuis trop longtemps ses clients pour des pigeons... Pour finir, les pigeons se révoltent et c'est... parfaitement normal!

  6. #6
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 498
    Points
    7 498

    Par défaut

    Citation Envoyé par Anselme45 Voir le message
    Pour info, les "SGBD Oracle", ce n'est rien d'autre que de la base de données SQL! A part de rares exceptions où il serait fait appel à des concepts très exotiques propres à Oracle, le remplacement d'une "SGBD Oracle" par une autre solution de base de données SQL se fait sans problème et surtout en refaisant le projet de la lettre A à ... La lettre B! Pas besoin de passer en revue les 26 lettres de l'alphabet
    C'est surtout si le projet contient des procédures stockées qu'il y a du taff.
    Par contre, pour le SQL de base, c'est particulièrement basique.

    Là où il y a du taf, c'est surtout du côté des administrateurs qui doivent revoir les proc de monitoring, de sauvegarde, d'indexation, vacuum, etc.
    Rien de bien méchant mais parfois chronophage.

  7. #7
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 246
    Points : 1 059
    Points
    1 059

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Là où il y a du taf, c'est surtout du côté des administrateurs qui doivent revoir les proc de monitoring, de sauvegarde, d'indexation, vacuum, etc.
    Rien de bien méchant mais parfois chronophage.
    Pense aux économies que l'entreprise va faire en n'ayant plus à envoyer ses admin Oracle suivre les cours à l'Oracle University (Put... Même là, ces c... se la pête!)

    Avec le fric économisé qu'il faut débourser à chaque nouvelle édition du sgbd Oracle, l'entreprise peut financer du temps pour les proc liés à la maintenance et même se payer une nouvelle imprimante pour imprimer des jolis certificats de formation avec entête "My University"

  8. #8
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 822
    Points : 2 953
    Points
    2 953

    Par défaut

    Tout refaire? Non dans le cadre d'un projet classique c'est le plus facile à changer.
    Ce n'est qu'un SGBD.
    Il y a sacré panel de SGBD SQL (Sql Server, MariaDb, Postgress SQL...).

    Concernant Amazon il doit y avoir une toute autre problématique: les serveurs dédiés et probablement fine-tunés.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  9. #9
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 822
    Points : 2 953
    Points
    2 953

    Par défaut

    Citation Envoyé par Anselme45 Voir le message
    Pense aux économies que l'entreprise va faire en n'ayant plus à envoyer ses admin Oracle suivre les cours à l'Oracle University (Put... Même là, ces c... se la pête!)

    Avec le fric économisé qu'il faut débourser à chaque nouvelle édition du sgbd Oracle, l'entreprise peut financer du temps pour les proc liés à la maintenance et même se payer une nouvelle imprimante pour imprimer des jolis certificats de formation avec entête "My University"
    Oui mais pense aussi aux frics qu'ils vont perdre quand leurs serveurs ne répondront pas, avec la charge non supportées.
    De quoi flinguer 2, 3 ingénieurs
    Si la réponse vous a aidé, pensez à cliquer sur +1

  10. #10
    Membre habitué
    Homme Profil pro
    Ergonome
    Inscrit en
    octobre 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : octobre 2016
    Messages : 63
    Points : 127
    Points
    127

    Par défaut

    Est-ce que les comportements des grands éditeurs ont des conséquences sur le choix de leurs clients malmenés de chercher à les remplacer ?
    La réponse est OUI et ça ne vaut pas que pour cet éditeur même s'il caricature le genre.

    Le temps des monopoles est révolu. Le software ne peut pas rester indéfiniment l'industrie la plus arrogante au monde.

    Par ailleurs, il me semble que les réactions ci-dessus ont oublié MongoDb et NoSql.

    Difficile d'estimer le coût moyen d'une migration mais force est de constater que les disques durs font 4 To et que SQL s’accommodait mieux de volumes 10 à 50 fois inférieurs à ceux qu'on rencontre aujourd'hui. Alors "technologie déclinante" ?

    Un peu à cause de sa gestion des index trop aléatoire et l'impossibilité jusqu'ici de mettre une clause WHERE dans un CREATE INDEX (le vieux Xbase le faisait pourtant...)

    SQL reste génial mais les gros volumes d'hier sont devenus petits et les SGBD ne sont plus la chasse gardée des deux premiers éditeurs mondiaux. A bons entendeurs, salut.
    Attention à Fred - Roman - Prophétie spatiale - action intrépide.

  11. #11
    Membre averti Avatar de Placide Avorton
    Homme Profil pro
    Technicien d'exploitation
    Inscrit en
    novembre 2014
    Messages
    181
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Technicien d'exploitation

    Informations forums :
    Inscription : novembre 2014
    Messages : 181
    Points : 411
    Points
    411

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Là où il y a du taf, c'est surtout du côté des administrateurs qui doivent revoir les proc de monitoring, de sauvegarde, d'indexation, vacuum, etc.
    Rien de bien méchant mais parfois chronophage.
    De plus une migration depuis Oracle vers un autre SGBD peut imposer selon la criticité des données d'effectuer des tests de restauration à partir des bandes archivées au bunker.

    Sûrement est-ce ce que tu appelle monitoring mais il faut également réviser les scenarios de supervision, les chaînes de traitement de l'ordonnanceur et les crontab.

    Puis enfin mettre à jour la documentation parfois foisonnante et dérouler les mises en production en heures non ouvrées...

    C'est une charge de travail dont Oracle a probablement conscience qu'elle dissuade des migrations et je m’inquiète d'ailleurs de voir les mêmes travers se dessiner avec le big data dont les solutions sont principalement propriétaires (en tout cas concernant le SI sur lequel je bosse).

  12. #12
    Membre habitué Avatar de steel-finger
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2013
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

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

    Informations forums :
    Inscription : janvier 2013
    Messages : 119
    Points : 181
    Points
    181

    Par défaut

    Nous on s'est fait attaqué pour une histoire de licence qu'ils ont voulus arrangés a leur sauce et depuis ce jour la, les produits Oracles c'est fini !

  13. #13
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 835
    Points
    13 835

    Par défaut

    Citation Envoyé par Anselme45 Voir le message
    Refaire le projet de A à Z? Rien que cela?
    bonjour je me suis fait mal comprendre sans doute étais-je insuffisament explicite.
    La problématique est la suivante : admettons que vous déclariez une classe Java ou C++ (ou C# ) donc vous déclarez la directive import ou #include sur une API Oracle pour piloter la base de donnée
    Ensuite admettons que cette classe serve à instancier un client en particulier (ceci à titre d'exemple) et que vous déclariez une méthode qui appelle directement une API Oracle pour lister les clients du SGBDR
    Eh bien si vous avez plusieurs classes avec des appels à des API Oracle ( ou autre SBGDR) ,du genre execute_procedure_stockee(), avec execute_procedure_stockee() répétée plusieurs fois c'est là où il va falloir refaire le code le cas échéant si vous changez de techno
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  14. #14
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 640
    Points : 5 780
    Points
    5 780
    Billets dans le blog
    5

    Par défaut

    Bonjour,


    Ce sont des annonces politiques et marketing faites par des companies rivales, bien loin des réalités techniques. C'est trés bien pour la compétition qui fait évoluer les produits. Mais l'inconvénient c'est que, comme toutes les startups et PME on l'habitude de s'identifier avec les géants, tout le monde pense pouvoir faire pareil.


    La raison invoquée dans l'article est l'incapacité à suivre la charge:
    The primary issue Amazon has faced on Oracle is the inability for the database technology to scale to meet Amazon's performance needs, a person familiar with the matter said.

    S'il y a une chose où Oracle a fait ses preuves, c'est sur les très grosses bases critiques (telecom, aerien, retail, CERN, ...). Personne ne peut concurrencer Parallel Query, Partitioning, RAC pour ces très grosses bases.


    Le marketing BigData et NoSQL a fait croire que le SQL est dépassé:
    Citation Envoyé par commandantFred Voir le message
    les disques durs font 4 To et que SQL s’accommodait mieux de volumes 10 à 50 fois inférieurs à ceux qu'on rencontre aujourd'hui. Alors "technologie déclinante" ?
    Un peu à cause de sa gestion des index trop aléatoire et l'impossibilité jusqu'ici de mettre une clause WHERE dans un CREATE INDEX (le vieux Xbase le faisait pourtant...)
    SQL reste génial mais les gros volumes d'hier sont devenus petits et les SGBD ne sont plus la chasse gardée des deux premiers éditeurs mondiaux. A bons entendeurs, salut.

    La particularité du SQL est qu'il travaille sur des ensembles de donnée et non ligne à ligne. Il est basé sur des concepts mathématiques. C'est un language de 4ème génération - un des seul en production aujourd'hui. Il est loin d'être dépassé par des langages de 3ème génération et des modèles hierarchiques (comme OO, XML, JSON) qui ont montré leurs limites il y a 30 ans, d'où l'invention du relationnel. D'ailleurs, Hadoop, Kafka,... se mettent au SQL. L'approche ensembliste est nécessaire aux gros volumes.

    @commandantFred J'aimerais bien voir la question sur les 'index trop aléatoires' et les index partiels dans le forum pour répondre la dessus.


    Certains pensent que la migration d'un SGBD à l'autre est facile. C'est loin d'être le cas dès qu'on a une application serieuse, multi-utilisateurs, avec un grand historique de données.


    Citation Envoyé par Anselme45 Voir le message
    Pour info, les "SGBD Oracle", ce n'est rien d'autre que de la base de données SQL! A part de rares exceptions où il serait fait appel à des concepts très exotiques propres à Oracle, le remplacement d'une "SGBD Oracle" par une autre solution de base de données SQL se fait sans problème

    Non, même les comportements les plus basiques sont très différentes. Un simple SELECT va verouiller sur certains SGBD, pas sur d'autres, et ne va pas montrer les mêmes données dès qu'il a d'autre utilisateurs en train de faire des modifications. C'est peut-être acceptable pour une appli simple et non-critique, mais pas pour un ERP. Et il est certain que si le but n'est d'utiliser que les fonctionnalités qui se trouvent dans SQLite, il ne faut pas acheter Oracle


    Citation Envoyé par Saverok Voir le message
    C'est surtout si le projet contient des procédures stockées qu'il y a du taff.
    Par contre, pour le SQL de base, c'est particulièrement basique.

    Au contraire, lorsque les accès à la base sont encapsulés dans des procédures, il est facile de les réécrire dans une autre langage. Et de tester les procédures de manière unitaire. Lorsque le code applicatif attaque directement les tables, c'est plus compliqué. Le but des vues et des procédures stockées est justement d'avoir une application (couches présentation et parfois business) indépendente de la plateforme.


    Citation Envoyé par hotcryx Voir le message
    Tout refaire? Non dans le cadre d'un projet classique c'est le plus facile à changer.
    Ce n'est qu'un SGBD.
    Il y a sacré panel de SGBD SQL (Sql Server, MariaDb, Postgress SQL...).

    Ils ont tous des comportements différents, visibles dans les performances mais aussi dans les données. Le travail gigantesque de migration n'est pas dans la réécriture du code mais dans les tests. Et peu d'éditeurs de logiciel on envie de se lancer dans ce travail. Sans parler de l'immense effort de re-design qu'il faudra faire pour retrouver des performances correctes car l'optimiseur d'oracle a, au fur et à mesure des version, intégré plein de workarounds pour des problèmes de performance applicatif. Les vendeurs de progiciels y réfléchissent, mais la réalité les ralentit. Le coût de développement peut être monstueux si l'on compare avec une application APEX par exemple.


    Puisque Amazon invoque des limites de performances, il s'agit d'un use-case bien précis où le relationnel a ses limites et où il faut troquer la flexibilité pour une solution dédiée. Ce qu'ont développé Google, Amazon, Facebook... dans des domaines précis est très bien. Mais penser qu'on peut faire pareil pour toutes les applis de toutes les entreprises est utopique. Un exemple: Google a développé Spanner pour remettre un peu de SQL et de relationnel dans son BigTable lorsque le NoSQL a montré ses limites. Mais il n'y a pas de types de donnée décimale. Ca ne pourra jamais remplacer un SGBDR existant sauf pour quelques cas particuliers. Vers PostgreSQL, d'autres problèmes: PostreSQL ne fait pas d'updates mais recopie toute la ligne. Un appli qui fait beucoup de mises à jour ne sera jamais scalable. Et pas d'opérations online: maintenance difficile sur une appli 24/7. Et les autres SGBD où les lectures bloquent les écritures. Il faudra tout réécrire sauf si l'application n'a qu'un seul utilisateur.


    Cordialement,
    Franck.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  15. #15
    Membre habitué
    Homme Profil pro
    Ergonome
    Inscrit en
    octobre 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : octobre 2016
    Messages : 63
    Points : 127
    Points
    127

    Par défaut

    Citation Envoyé par pachot Voir le message
    S'il y a une chose où Oracle a fait ses preuves, c'est sur les très grosses bases critiques (telecom, aerien, retail, CERN, ...). Personne ne peut concurrencer Parallel Query, Partitioning, RAC pour ces très grosses bases.

    Le marketing BigData et NoSQL a fait croire que le SQL est dépassé:

    La particularité du SQL est qu'il travaille sur des ensembles de donnée et non ligne à ligne. Il est basé sur des concepts mathématiques. C'est un language de 4ème génération - un des seul en production aujourd'hui. Il est loin d'être dépassé par des langages de 3ème génération et des modèles hierarchiques (comme OO, XML, JSON) qui ont montré leurs limites il y a 30 ans, d'où l'invention du relationnel. D'ailleurs, Hadoop, Kafka,... se mettent au SQL. L'approche ensembliste est nécessaire aux gros volumes.

    @commandantFred J'aimerais bien voir la question sur les 'index trop aléatoires' et les index partiels dans le forum pour répondre la dessus.

    Certains pensent que la migration d'un SGBD à l'autre est facile. C'est loin d'être le cas dès qu'on a une application serieuse, multi-utilisateurs, avec un grand historique de données.

    Non, même les comportements les plus basiques sont très différentes. Un simple SELECT va verouiller sur certains SGBD, pas sur d'autres, et ne va pas montrer les mêmes données dès qu'il a d'autre utilisateurs en train de faire des modifications. C'est peut-être acceptable pour une appli simple et non-critique, mais pas pour un ERP. Et il est certain que si le but n'est d'utiliser que les fonctionnalités qui se trouvent dans SQLite, il ne faut pas acheter Oracle
    (...)
    Cordialement,
    Franck.
    Bon, les "concepts mathématiques" de SQL coté dev, c'est la théorie des ensembles qu'on a tous appris en 6eme... Vous restez sur des notions très théoriques, j'ai travaillé sur une dizaine de front ends Oracle (mais pas que...)

    Non, le NoSQL n'est pas un mouvement né du marketing. Il est arrivé avec les sites web à très forte charge (10 ^ 8/jour). Les bases noSQL ont été développées en interne chez ces fournisseurs pour faire sauter les goulots d'étranglement de SQL (d'où le nom). Ce n'est qu'ensuite qu'ils ont été mis aux normes pour être distribués et que le marketing s'y est intéressé.

    Encore une fois, je n'ai rien contre SQL, au contraire, je continuerai à l'employer à cause de sa formidable facilité d'utilisation. Mais il faut remettre les choses dans le contexte : SQL régnait en maître alors que les bases de données se limitaient aux logiciels spécifiques qui proposaient surtout des formulaires à remplir et des choses comme ça. Les gros volumes de l'époque dépassaient rarement les 10 milliards de lignes.

    Aujourd'hui que fait-on avec dix giga-lignes quand ont est un GAFAM.. ?? Pas grand chose...

    La limitation structurelle de SQL dans les très gros datasets provient de la conception de ses indexes. Disons pour faire simple, que ses concepteurs ont souhaité rendre les indexes aussi transparents que possible. Leur usage dans une recherche est implicite ou encore 'aléatoire' parce qu'il est quasi-impossible de forcer SQL à utiliser un index précis sans passer par les spécificités constructeur. Sous oracle, ça passe par l'ajout d'un hint en commentaire dans la clause select (que le schema d’exécution ne respecte pas toujours). Sur d'autres implémentations, il faut faire des acrobaties absurdes, non-portables et ALEATOIRES dans leurs comportements.

    Si vous avez fait un peu de gros volumes (tera-lignes) , vous réaliserez tôt ou tard que les index SQL sont inadaptés.
    J'en ai fait la cruelle expérience le mois dernier sur une requête portant sur 300 milliards de lignes dont l'index avait été désynchronisé par un client situé de l'autre coté de la planète. Résultat au lieu de durer 2 heures, la requête s’exécute en ... 15 ans ? 150 ans ? Je n'ai pas attendu pour vérifier...

    Le modèle conceptuel de SQL prévoit de limiter la portée des requêtes en passant par les VIEWS mais aussi géniales soient elles, ce ne sont pas des indexes. La performance n'est pas au rendez-vous. Je soupçonne les VIEWS de n'avoir été implémentées que pour simplifier la SYNTAXE des requêtes et non pas les perfs.

    J'en reviens donc à ce que je disais plus haut. Tant que SQL n'autorise pas de WHERE dans le CREATE INDEX ni l'ouverture d'un index comme une table (figurer dans une clause SELECT), il sera condamné à rester aux volumes des années 90 (fichiers sécu, impôts et douanes américaines) mais ne pourra pas s’accommoder des volumes d'aujourd'hui.
    Attention à Fred - Roman - Prophétie spatiale - action intrépide.

  16. #16
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 321
    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 : 18 321
    Points : 42 824
    Points
    42 824

    Par défaut

    Citation Envoyé par commandantFred Voir le message
    Difficile d'estimer le coût moyen d'une migration mais force est de constater que les disques durs font 4 To et que SQL s’accommodait mieux de volumes 10 à 50 fois inférieurs à ceux qu'on rencontre aujourd'hui. Alors "technologie déclinante" ?
    je pense que vous êtes un peu à côté de la plaque... Personnellement j'ai plus d'une vingtaines de clients qui ont des bases de plusieurs dizaines de To (SQL Server)...

    Un peu à cause de sa gestion des index trop aléatoire et l'impossibilité jusqu'ici de mettre une clause WHERE dans un CREATE INDEX (le vieux Xbase le faisait pourtant...)
    La clause WHERE des index est supportée dans la plupart des SGBDR. La compression des index aussi dans les grands SGBDR (Oracle, SQL Server...). Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE

    SQL reste génial mais les gros volumes d'hier sont devenus petits et les SGBD ne sont plus la chasse gardée des deux premiers éditeurs mondiaux. A bons entendeurs, salut.
    La plupart des grands éditeurs (IBM, Oracle, MS) ont intégrés des technologies mature venant du NoSQL comme (je parle pour SQL Server) :
    • les types objets, notamment : XML, geometry, geography, JSON...
    • la modification à chaud des structures de données (pas de blocage des données des tables en cours de restructuration)
    • la création/reconstruction à chaud des index (pas de blocage des données lors de la création et la maintenance des index)
    • Le partitionnement des tables
    • la réplication des données entre divers noeuds (7 mécanismes différents dans SQL Server
    • la haute disponibilité des nœuds (à na pas confondre avec la réplication des données)
    • la compression des données et index
    • les tables "in memory"
    • les procédures stockées compilées en mode natif (C)
    • l'indexation verticale ("columnstore")
    • l'indexation des documents électroniques (type bases documentaire NoSQL)
    • les vues indexées
    • l'indexation sémantique (genre "elastic search")
    • les tables de nœuds et d'arêtes ("graph database")

    Tout ceci est disponible dans SQL Server... Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...
    un Seul SGB NoSQL est capable de faire plusieurs de ces choses : Cosmos DB... et je vous laisse deviner qui en est l'éditeur !

    À lire : https://blog.developpez.com/sqlpro/p...l-a-tout-faire

    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 * * * * *

  17. #17
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 321
    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 : 18 321
    Points : 42 824
    Points
    42 824

    Par défaut

    Citation Envoyé par commandantFred Voir le message
    Bon, les "concepts mathématiques" de SQL coté dev, c'est la théorie des ensembles qu'on a tous appris en 6eme... Vous restez sur des notions très théoriques, j'ai travaillé sur une dizaine de front ends Oracle (mais pas que...)

    Non, le NoSQL n'est pas un mouvement né du marketing. Il est arrivé avec les sites web à très forte charge (10 ^ 8/jour). Les bases noSQL ont été développées en interne chez ces fournisseurs pour faire sauter les goulots d'étranglement de SQL (d'où le nom). Ce n'est qu'ensuite qu'ils ont été mis aux normes pour être distribués et que le marketing s'y est intéressé.
    Vous confondez NoSQL et Big Data. Aucun site web marchand n'a 300 milliards de lignes dans ses tables. Et presque tous utilisent des SGBDR Relationnels gérant des transaction pour la partie marchande, même AMAZON... ! Pour info, en France, TOUS les gros sites web marchand sont sur des SGBDR (Fnac, CDiscount, Ventes Privées => SQL Server, tgv.com => Oracle...)

    Encore une fois, je n'ai rien contre SQL, au contraire, je continuerai à l'employer à cause de sa formidable facilité d'utilisation. Mais il faut remettre les choses dans le contexte : SQL régnait en maître alors que les bases de données se limitaient aux logiciels spécifiques qui proposaient surtout des formulaires à remplir et des choses comme ça. Les gros volumes de l'époque dépassaient rarement les 10 milliards de lignes.

    Aujourd'hui que fait-on avec dix giga-lignes quand ont est un GAFAM.. ?? Pas grand chose...

    La limitation structurelle de SQL dans les très gros datasets provient de la conception de ses indexes.
    Renseignez-vous il existe des technologies d'indexation pour les très grosses tables. C'est le cas des index columstore de SQL Server qui ne sont réellement utilisable qu'a partir de 100 millions de lignes, car ils travaillent avec des "pages" de 1 million de lignes au minimum...
    Disons pour faire simple, que ses concepteurs ont souhaité rendre les indexes aussi transparents que possible. Leur usage dans une recherche est implicite ou encore 'aléatoire' parce qu'il est quasi-impossible de forcer SQL à utiliser un index précis sans passer par les spécificités constructeur. Sous oracle, ça passe par l'ajout d'un hint en commentaire dans la clause select (que le schema d’exécution ne respecte pas toujours). Sur d'autres implémentations, il faut faire des acrobaties absurdes, non-portables et ALEATOIRES dans leurs comportements.

    Si vous avez fait un peu de gros volumes (tera-lignes) , vous réaliserez tôt ou tard que les index SQL sont inadaptés.
    J'en ai fait la cruelle expérience le mois dernier sur une requête portant sur 300 milliards de lignes dont l'index avait été désynchronisé par un client situé de l'autre coté de la planète. Résultat au lieu de durer 2 heures, la requête s’exécute en ... 15 ans ? 150 ans ? Je n'ai pas attendu pour vérifier...

    Le modèle conceptuel de SQL prévoit de limiter la portée des requêtes en passant par les VIEWS mais aussi géniales soient elles, ce ne sont pas des indexes.
    Sans doute ne connaissez vous pas le concept de vues indexées ou vues matérialisées....

    La performance n'est pas au rendez-vous. Je soupçonne les VIEWS de n'avoir été implémentées que pour simplifier la SYNTAXE des requêtes et non pas les perfs.

    J'en reviens donc à ce que je disais plus haut. Tant que SQL n'autorise pas de WHERE dans le CREATE INDEX ni l'ouverture d'un index comme une table (figurer dans une clause SELECT), il sera condamné à rester aux volumes des années 90 (fichiers sécu, impôts et douanes américaines) mais ne pourra pas s’accommoder des volumes d'aujourd'hui.
    Révisez vos jugements hâtifs et travaillez avec un vrai SGBDR !!!

    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 * * * * *

  18. #18
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 640
    Points : 5 780
    Points
    5 780
    Billets dans le blog
    5

    Par défaut

    Bonjour,


    >> théorie des ensembles qu'on a tous appris en 6eme
    On va un peu plus loin quand on y ajoute des notions de transaction, cohérence de données,... La base mathématique de l'algèbre relationnelle est à mon avis la raison pour laquelle elle dure plus longtemps que les autres modes (des souvenirs des SGBDOO?) est n'est pas liée à l'époque ou au volume.


    >> NoSQL ... pour faire sauter les goulots d'étranglement de SQL
    Le retour aux modèles hierarchiques (car pas de jointure) et L3G (procédural) a été nécessaire pour des cas très particulier. Un peu comme certaines applis ont toujours des modules en assembleur pour des parties très critiques en performance. Ces use-cases ont été intégrés dans les SGBDR (objet-relationnel, XML, JSON,...).

    >> acrobaties absurdes, non-portables et ALEATOIRES dans leurs comportements
    Non, pas aléatoire. Le choix de l'index est fait par l'optimiseur et est complètement déterminé par les moyens d'accès et des statistiques. C'est complètement deterministic, et c'est le seul moyen correct d'avoir un accès performant et prédictible sans avoir à coder chaque cas particulier.


    >> index avait été désynchronisé
    Quel SGBD? Je pensais que la maintenance des index était toujours synchrone.


    >> VIEWS de n'avoir été implémentées que pour simplifier la SYNTAXE
    Les vues c'est ni pour la syntaxe ni pour les perfs mais pour une vue logique indépendante de l'implémentation physique


    >> les VIEWS mais aussi géniales soient elles, ce ne sont pas des indexes
    Les vues matérialisées, elles sont très similaires: stockage redondant, synchrone ou asnychrone, optimisé pour certains types de requêtes.


    >> WHERE dans le CREATE INDEX
    ça existe sur plusieurs SGBD, pas forcément nécessaire sur d'autres (car partitionnement, materialized views, storage index). Mais surtout, c'est souvent le partitionnement qui répond au besoin d'indexation partiel. La taille d'un index B-Tree n'impacte pas (ou très peu - une page de plus à lire en cache) la performance d'accès par index.
    Au passage, Oracle n'implémente pas les index partiels mais l y a des moyens de faire la même chose (cf. https://blog.dbi-services.com/postgr...ess-paths-iii/)


    Maintenant, concrètement, cette requête sur 300 milliards de lignes:
    - si on veut récupérer 10 lignes sur les 300M un index B-Tree est parfait pour ça. Disons au pire 5 branches d'index à lire puis 10 accès à la table. 15 x 8 millisecondes si rien n'est en cache et stocké sur un vieux disque mécanique. C'est moins que la latence réseau du 'client situé de l'autre coté de la planète'
    - si c'est 1000 lignes, 10000 c'est linéaire. L'accès par index est proportionnel au nombre de lignes lues, pas à la taille de la table
    - si on veut récupérer 10 milliards de lignes, pas besoin d'index. Full Table Scan ira beaucoup plus vite. Là ça dépend de la taille de la table et non plus du nombre de lignes retournées.
    - 100000 lignes: covering index peut être utile (plus besoin d'aller voir la table pour chaque ligne)
    - 500000 lignes: partitionnement. De toute façon, une table de plusieurs millions de lignes devrait être partitionnée déjà pour des raisons de performance.


    C'est des exemples mais les SGBD se sont adaptés depuis longtemps (~ 20 ans) à ces volumes avec partitionnement, parallel query, compression,... Les SGBD les plus puissants on aussi du columnar store, storage index, pour ces use cases. Et un optimiseur qui va choisir le plan optimal en fonction du résultat demandé, car le développeur ne sait pas toujours combien de lignes seront retournées par une requête. cf. exemple de plan adaptif sur Oracle qui parle du point d'inflexion entre accès index v. full scan: https://blog.dbi-services.com/oracle...flexion-point/

    Mais bien sûr, tout ce qu'on peut faire avec un L4G comme SQL peut se faire avec un L3G. Mais c'est un effort énorme, surtout si on tient compte de tout le cycle de vie des données (sécurité, disponibilité, backups, troubleshooting,...).

    Cordialement,
    Franck.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  19. #19
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 640
    Points : 5 780
    Points
    5 780
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE
    Hello SQLPro,

    En fait, j'ai toujours été surpris qu'Oracle n'ait pas implémenté ce INCLUDE mais d'une part j'en ai rarement vu le besoin. Et la raison est probablement que d'autres optimisations qui sont là depuis longtemps remplissent un peu le même rôle: https://blog.dbi-services.com/coveri...d-branch-size/

    Cordialement,
    Franck.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  20. #20
    Membre habitué
    Homme Profil pro
    Ergonome
    Inscrit en
    octobre 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : octobre 2016
    Messages : 63
    Points : 127
    Points
    127

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    je pense que vous êtes un peu à côté de la plaque... Personnellement j'ai plus d'une vingtaines de clients qui ont des bases de plusieurs dizaines de To (SQL Server)... La clause WHERE des index est supportée dans la plupart des SGBDR. La compression des index aussi dans les grands SGBDR (Oracle, SQL Server...). Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE
    La plupart des grands éditeurs (IBM, Oracle, MS) ont intégrés des technologies mature venant du NoSQL comme (je parle pour SQL Server) :
    • les types objets, notamment : XML, geometry, geography, JSON...
    • la modification à chaud des structures de données (pas de blocage des données des tables en cours de restructuration)
    • la création/reconstruction à chaud des index (pas de blocage des données lors de la création et la maintenance des index)
    • Le partitionnement des tables
    • la réplication des données entre divers noeuds (7 mécanismes différents dans SQL Server
    • la haute disponibilité des nœuds (à na pas confondre avec la réplication des données)
    • la compression des données et index
    • les tables "in memory"
    • les procédures stockées compilées en mode natif (C)
    • l'indexation verticale ("columnstore")
    • l'indexation des documents électroniques (type bases documentaire NoSQL)
    • les vues indexées
    • l'indexation sémantique (genre "elastic search")
    • les tables de nœuds et d'arêtes ("graph database")

    Tout ceci est disponible dans SQL Server... Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...
    un Seul SGB NoSQL est capable de faire plusieurs de ces choses : Cosmos DB... et je vous laisse deviner qui en est l'éditeur !

    À lire : https://blog.developpez.com/sqlpro/p...l-a-tout-faire

    A +

    Ok, je viens d'apprendre des choses sur SQL Server. Oracle ne fait pas ça correctement.

    Reste que vous présentez ça comme une évidence depuis toujours alors que NoSql s'est développé à une époque où les indexes filtrés étaient impossibles en sql.
    Le reste des features est un peu encombrant dans cette conversation.

    A eux seuls les indexes filtrés justifient les problèmes d'Oracle (sujet de l'article).
    300 milliards de lignes est effectivement un volume auquel j'ai affaire sous Oracle.

    EDIT
    Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...

    On ne développe pas en NoSQL pour cloner les features d'un SGBD concurrent ! Il ne s'agit pas de participer à la grande bataille des SGBD mais de faire tourner un SI qui a ses propres besoins. Ces tâches sont conçues spécifiquement avec une certaine créativité... Si vous me permettez, je n’achèterai sans doute jamais de SGBDR parce que je contourne les limites de ceux qui existent. Bien sûr, je peux me tromper et "tomber" pour SQL server mais je crains un peu de ne plus pouvoir travailler sans ensuite et d'être obligé de demander à mes clients d'ouvrir un compte hotmail pour activer leur SI ...

    EDIT
    Finalement, les deux grands éditeurs de SGBD se ressemblent. Au début, ils sont sympas et souriants. Ensuite ils vous demandent de payer des choses, puis d'afficher leur logo sur votre porte. Enfin , ils vous expliquent que vous ne seriez rien sans eux et qu'à ce titre, votre boite leur appartient un peu. N'est-ce pas exactement ce qu'on reproche à l'un d'eux ici ?
    Attention à Fred - Roman - Prophétie spatiale - action intrépide.

Discussions similaires

  1. Microsoft dévoile les preview des logiciels Oracle sur Windows Azure
    Par Hinault Romaric dans le forum Microsoft Azure
    Réponses: 2
    Dernier message: 17/03/2014, 09h20
  2. Réponses: 2
    Dernier message: 21/08/2009, 14h41
  3. Impossible de télécharger des logiciels Oracle
    Par awalter1 dans le forum Installation
    Réponses: 7
    Dernier message: 20/09/2008, 09h18
  4. Oracle Forms6i Gestion des messages Oracle
    Par macyas dans le forum Forms
    Réponses: 9
    Dernier message: 31/01/2008, 17h58
  5. Des logiciels pour l'analyse des fichiers log
    Par maya dans le forum Réseau
    Réponses: 3
    Dernier message: 14/04/2007, 23h27

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