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

Affichage des résultats du sondage: Quels étaient vos SGBD préférés en 2017 (tous modèles confondus) ?

Votants
39. Vous ne pouvez pas participer à ce sondage.
  • Oracle

    2 5,13%
  • MariaDB

    4 10,26%
  • MySQL et autres dérivés

    6 15,38%
  • DB2

    1 2,56%
  • MS Access

    1 2,56%
  • Cassandra

    0 0%
  • SQLite

    5 12,82%
  • SQL Server

    15 38,46%
  • MongoDB

    2 5,13%
  • PostgreSQL

    15 38,46%
  • Firebird

    3 7,69%
  • Sybase

    0 0%
  • Autre (à préciser)

    0 0%
  • Pas d'avis

    0 0%
Sondage à choix multiple
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    2 045
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 045
    Points : 65 557
    Points
    65 557
    Billets dans le blog
    2

    Par défaut DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017

    DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017
    Quels étaient vos SGBD préférés en 2017 ?

    Comme il est de coutume depuis ces dernières années, le site DB-Engines, spécialisé dans le classement des moteurs de base de données, a livré son classement pour l’année qui vient de s’écouler. Au total, 341 systèmes de gestion de base de données (répartis entre différents modèles de bases de données) étaient en course pour le titre du SGBD de l’année 2017.

    Il faut noter que le titre de SGDB de l'année est décerné au système qui enregistre la plus forte hausse en popularité (et non la popularité absolue) au cours de l'année en question. Le classement de DB-Engines ne mesure pas non plus le nombre d'installations des SGBD ni leur utilisation dans les systèmes informatiques. La popularité d'un système de gestion de base de données telle que mesurée par le classement DB-Engines se base en effet sur les paramètres suivants :

    • le nombre de fois que le système est mentionné sur les sites web. Cette statistique est mesurée par le nombre de résultats de recherche dans les moteurs Google et Bing. Afin de compter seulement les résultats pertinents, les requêtes doivent inclure le mot-clé « database » ainsi que le nom du SGBD ;
    • la fréquence des recherches dans Google Trends ;
    • la fréquence des discussions techniques sur le système. Cette statistique est mesurée par le nombre de questions connexes et le nombre d’utilisateurs intéressés sur Stack Overflow et DBA Stack Exchange ;
    • le nombre d’offres d’emploi dans lesquelles le système est mentionné sur Indeed et Simply Hired ;
    • le nombre de profils sur les réseaux professionnels, dans lesquels le système est mentionné. Le réseau social utilisé ici est LinkedIn ;
    • la pertinence sur les réseaux sociaux, mesurée par le nombre de tweets dans lesquels le système est mentionné.

    En se basant sur ces critères, PostgreSQL est le SGBD qui a gagné le plus en popularité dans le classement DB-Engines au cours de la dernière année, c'est pourquoi il a été déclaré SGBD de l'année 2017. PostgreSQL a en effet enregistré un gain total de 55,81 points (+17 %) au cours de l'année 2017. D'après DB-Engines, la nouvelle version PostgreSQL 10 a certainement contribué à stimuler davantage l'intérêt pour le SGBD. « Avec l'introduction du partitionnement déclaratif, l'amélioration du parallélisme des requêtes, la réplication logique et la validation par quorum pour les réplications synchrones, PostgreSQL 10 s'est spécifiquement concentré sur les améliorations pour distribuer efficacement les données sur plusieurs nœuds. »


    Après PostgreSQL viennent ElasticSearch (à la deuxième place) et MariaDB (en troisième position). ElasticSearch a vu son score augmenter de 16,38 points (+ 15 %) en 2017. Deux faits, selon DB-Engines, peuvent avoir contribué à ce succès : la sortie d'ElasticSearch 6 en novembre dernier et l'effort d'Elastic, la société derrière ElasticSearch, de créer avec Elastic Stack un écosystème autour d'ElasticSearch, y compris des outils pour la collecte de données, la visualisation de données et l'apprentissage automatique. MariaDB a, quant à lui, amélioré son score de 13,26 points (+29 %) en 2017.

    Il faut noter ici que ce n'est pas le pourcentage d'évolution des scores de popularité qui est regardé pour déterminer le SGBD de l'année. Mais c'est plutôt la différence entre les scores de popularité au début de deux années successives (ici janvier 2017 et janvier 2018), parce que cela permet de ne pas favoriser les SGBD avec une faible popularité au début de l'année.

    Il faut aussi préciser que pour le titre de SGBD de l'année, PostgreSQL succède à SQL Server de Microsoft (vainqueur en 2016) et Oracle Database, SGBD de l'année 2015. En ce qui concerne la popularité absolue des SGBD, Oracle reste cependant encore leader devant MySQL et SQL Server. Ci-dessous le top 10 de DB-Engines.


    Sources : Blog DB-Engines, DB-Engines Ranking

    Et vous ?

    Que pensez-vous de ce classement ?
    Quels ont été vos SGBD préférés en 2017 ? Selon quels critères ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé

    Profil pro
    Chef de Projet / Développeur
    Inscrit en
    juin 2002
    Messages
    420
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chef de Projet / Développeur
    Secteur : Santé

    Informations forums :
    Inscription : juin 2002
    Messages : 420
    Points : 979
    Points
    979

    Par défaut

    Que pensez-vous de ce classement ?

    Access seulement 3 places derrière PostGresSQL et loin devant MariaDB.
    EnterpriseDB, 100 places derrières sa version Open Source (alors que c'est fondamentalement le même logiciel)

    Ce classement de popularité ne renseigne sur rien d'autre que ... la popularité.
    --
    vanquish

  3. #3
    Membre habitué
    Homme Profil pro
    Voyages à dos de Pangolins (Parce que j'aime les pagolins)
    Inscrit en
    juin 2017
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Autre

    Informations professionnelles :
    Activité : Voyages à dos de Pangolins (Parce que j'aime les pagolins)

    Informations forums :
    Inscription : juin 2017
    Messages : 60
    Points : 155
    Points
    155

    Par défaut

    Citation Envoyé par vanquish Voir le message

    Ce classement de popularité ne renseigne sur rien d'autre que ... la popularité.
    A condition qu'il soit répertorié dans le classement pour qu'on puisse voter pour. Même si une liste exhaustive existe, les listes de vote sont souvent fermés. Ceci dit, l'open-source devient de plus en plus populaire et c'est une bonne chose à mon sens.

  4. #4
    Futur Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2017
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

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

    Informations forums :
    Inscription : août 2017
    Messages : 6
    Points : 9
    Points
    9

    Par défaut

    Ce qui est sur c'est que les bases postgresql poussent comme des champignons ces derniers temps.

    Après, sur la base préférée, on aura des dizaines de réponses différentes.
    Certains regarderont le coût des licences (je parle ici de versions payantes) et s'orienteront vers pg (par exemple enterprisedb) ou mysql ou autres.
    D'autres, en faisant abstraction de ces coûts de licence, regarderont la robustesse, les fonctionnalités, la performance et se tourneront vers oracle, db2 et sql server (qui pour moi sont au dessus de la mêlée).
    D'autre, un peu de tout ça et on aura un autre résultat.

  5. #5
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 881
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 881
    Points : 8 878
    Points
    8 878
    Billets dans le blog
    1

    Par défaut

    Comme tout classement, les critères retenus sont au moins aussi importants que le résultat et l'interprétation peut varier.

    Par exemple, le critère "nombre de recherches dans Google" signifie un réel intérêt pour le SGBD, mais peut aussi être symptomatique d'un manque de documentation de la part de l'éditeur.

    Pour parler du SGBD que je connais le mieux, à savoir DB2 for Z/OS (la version mainframe donc), il n'existe quasiment pas de documentation hors doc officielle IBM car celle-ci est extrêmement riche et précise, les recherches se font essentiellement sur le site IBM et au sein de forums consacrés. Point de recherche Google donc

    Autre exemple, le critère "nombre d’offres d’emploi dans lesquelles le système est mentionné sur Indeed et Simply Hired", ces sites représentent quelle proportion du marché de l'emploi informatique ?
    Dans le monde ? en Europe ? en France ?

    D'ailleurs je n'ai pas vu sur quel secteur géographique était effectué le classement

    Etc...

    Donc, ce classement en vaut un autre, il faut juste utiliser la bonne grille de lecture

  6. #6
    Membre actif
    Profil pro
    Inscrit en
    mars 2006
    Messages
    160
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 160
    Points : 219
    Points
    219

    Par défaut

    J'ai voté pour PostgreSQL car ce système est vraiment sympa. Par rapport à MySQL/MariaDB qui à toujours des bizarreries genre lorsque l'on met une chaîne trop longue elle est enregistrée tronquée. La possibilité de faire des modifications sur les tables (drop/create/alter ...) dans des transactions est très pratique en phase de développement. PostgreSQL est aussi très complet.

    Coté inconvénients je dirais les migrations qui peuvent être assez compliqués et surtout longues lorsque l'on passe d'une version majeure à l'autre.

    J'aime pas mal SQLite pour des usages en lecture seule, typiquement pour une publication d'observations qui n'est complété que par tous les plusieurs mois ou moins. Cela permet d'avoir juste un fichier à déployer et archiver.

    Pour ce qui est des privateur à mon travail c'est quasi interdit car manque de maîtrise sur les données et le fait de ne pas pouvoir changer de fournisseur est particulièrement craint. Il faut dire que l'on nous à déjà fait une vacherie un fournisseur qui multiplie x10 le prix sans possibilité de changer . Résultat : projet abandonné. De plus la liberté d'installer n'importe où est très pratique (duplications de VMs, sur PC portable par exemple).

  7. #7
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    639
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 639
    Points : 1 118
    Points
    1 118

    Par défaut

    Citation Envoyé par one_eye Voir le message
    Après, sur la base préférée, on aura des dizaines de réponses différentes.
    Certains regarderont le coût des licences (je parle ici de versions payantes) et s'orienteront vers pg (par exemple enterprisedb) ou mysql ou autres.
    D'autres, en faisant abstraction de ces coûts de licence, regarderont la robustesse, les fonctionnalités, la performance et se tourneront vers oracle, db2 et sql server (qui pour moi sont au dessus de la mêlée).
    .
    La vérité c'est que l'on ne peux pas faire totalement abstraction du coût quelque soit l'entreprise. SQL Server n'est pas plus performant ou robuste qu'un bon MariaDB ou PostgreSQL. Oracle est peut être plus performant mais beaucoup trop cher et complexe pour une très large majorité des utilisations (y compris dans les très grosses et riches entreprises). On ne peux pas non plus oublier le côté souplesse et migration... Le tout fais que dans la majorité des cas les bonnes solutions Open-Source l'emportent au delà de toute considérations politique et polémique.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

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

    Par défaut

    Citation Envoyé par abriotde Voir le message
    La vérité c'est que l'on ne peux pas faire totalement abstraction du coût quelque soit l'entreprise. SQL Server n'est pas plus performant ou robuste qu'un bon MariaDB ou PostgreSQL.
    Vous dites n'importe quoi. Non seulement SQL Server et nettement plus performant que PG, il suffit de lire de bons benchmarks (par exemple celui-ci : http://g-ernaelsten.developpez.com/t...-performances/ juste entre 4 et 10 fois plus rapide...) mais il est même nettement plus performant qu'Oracle pour un prix entre 4 et 25 fois moins cher...

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

  9. #9
    Futur Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2017
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

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

    Informations forums :
    Inscription : août 2017
    Messages : 6
    Points : 9
    Points
    9

    Par défaut

    Non SQL Server n'est pas nettement plus performant qu'oracle et oui on ne peux pas faire totalement abstraction du coût quelque soit l'entreprise.
    Même si j'aime beaucoup postgresql, certaines fonctionnalités restent à améliorer (ça viendra au fur et à mesure des années j’espère).

    Pour le coût des licences, ça dépend des négociations ...

    Par exemple sur un serveur 2*6 core (tarifs négociés) :
    mysql Enterprise sur 3 ans (licence au serveur. Même prix chaque année) : 10-12k au total
    postgresql (avec distrib enterprisedb) sur 3 ans (licence au nb de cœurs. Même prix chaque année) : 30-35k au total
    sql server enterprise : la je ne sais pas comment on compte (nous sommes dans des licences par cœurs). Pour les coût d'acquisition de licence c'est simple (prix public pour 2 coeurs : 14k) mais pour les années suivantes, je ne sais pas comment ça marche (rien, même prix chaque ou coût de maintenance)
    db2 enterprise sur 3 ans (licence au nb de cœurs. Coût acquisition licence 1er année, puis maintenance sur les années suivantes): 100k au total
    oracle enterprise sur 3 ans (licence au nb de cœurs. Coût acquisition licence 1er année, puis maintenance sur les années suivantes) : je ne sais plus mais plus cher encore.

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

    Par défaut

    Citation Envoyé par one_eye Voir le message
    Non SQL Server n'est pas nettement plus performant qu'oracle
    Ha oui et que pensez vous de cet autre test :
    https://www.periscopedata.com/blog/c...ver-and-oracle
    "In all three examples, SQL Server outperformed Oracle by about 25-40%."

    Il y a beaucoup d'autres exemples ou SQL Server obtient des performances très supérieures à Oracle. Ce qui pèche chez Oracle c'est son optimiseur qu'il faut sans arrêt bricoler pour avoir des performances justes acceptable, alors que sous SQL Server il est rare de devoir rajouter des "hint"...

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

  11. #11
    Futur Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2017
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

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

    Informations forums :
    Inscription : août 2017
    Messages : 6
    Points : 9
    Points
    9

    Par défaut

    Je ne me sers pas trop des benchs trouvés sur internet. On peut leur faire dire tout et son contraire. Mais ça peut me donner des infos sur certaines problématiques.
    Pour l'optimiseur d'oracle, je suis d'accord. Pour avoir fait, il y a quelques années, une migration de db2 9.5 linux vers oracle 11g linux, j'ai trouvé l'optimiseur db2 meilleur.
    Mais, l'utilisation des hints avec oracle permet de compenser.

    Et pour ma culture perso, comment est calculé le cout des licences (celle par core) sql server. Cout d'acquisition la premiere année (prix public d'une enterprise : 7k/core), et maintenance les années suivantes ?

  12. #12
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 692
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 692
    Points : 16 033
    Points
    16 033

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Il y a beaucoup d'autres exemples ou SQL Server obtient des performances très supérieures à Oracle. Ce qui pèche chez Oracle c'est son optimiseur qu'il faut sans arrêt bricoler pour avoir des performances justes acceptable, alors que sous SQL Server il est rare de devoir rajouter des "hint"...
    Déjà séparons les besoins OLTP / R-OLAP. Les exemples dont je parle ci-dessous sont du vécu sur les versions Oracle 11gR2 et SQL-Server 2008 R2 SP2 (je ne sais plus, c'était en 2013-2014).

    Côté OLTP, les deux optimiseurs sont excellents du moment que la base est bien modélisée et indexée.
    Si vous avez beaucoup (plus de 100 agents qui lancent chacun un 100aine de requêtes par seconde) de concurrence, ça commence à sentir pas très bon pour SQL-Server. Vous avez le choix entre des verrous de lecture à chaque requête (si vous venez d'Oracle, constater qu'un select pose un verrou bloquant c'est surprenant), ou bien des dirty read (et de surcroît il y a un bug sur les dirty read où parfois ça génère un doublon, même en lecture sur une table avec une PK).
    Dans un grand site de vente en ligne qui tourne, ils ont opté pour les dirty read, non pas par amour mais parce que les autres modes d'isolation ne font pas le job, soit à cause des verrous soit à cause des performances.
    Le comité exécutif sait que tous ses reportings de vente a un marge d'erreur d'environ 1%.
    Donc oui pour revenir aux hints, l'utilisation des dirty read se faisait en précisant à chaque appel de vue / table dans tous les scripts, fonctions et procédures, un petit (read uncommitted) systématique. Ça fait pas mal de rajouts de hint in fine.

    Côté R-OLAP, l'optimiseur d'Oracle va commencer à pêcher sur des requêtes de plusieurs milliers de lignes (la requête, pas le contenu des tables).
    SQL-Server est très vite à la ramasse. Les jointures avec beaucoup de colonnes ont des performances moins bonnes qu'en calculant un hash de toutes les colonnes, en gardant à l'esprit les problèmes inhérents aux hashs.

    Les requêtes avec beaucoup de niveaux, idem SQL-Server est poussif.
    En général sur Oracle on lance une grosse requête, là où sur SQL-Server il vaut mieux créer plein de tables temporaires pour stocker les résultats intermédiaires, justement pour palier la faiblesse de l'optimiseur de SQL-Server.
    Alors oui, on met des hints sur Oracle pour changer ci ou ça, mais y'a pas photo au final, on bricole moins à écrire quelques hints qu'à réécrire tout un traitement.

    Maintenant, les deux bases sont quand même très robustes et en général si on a l'une ou l'autre ça ne vaut pas le coup de migrer pour celle d'en face, sauf usage bien précis (typiquement, les DWH sur SQL-Server, c'est mauvais).

    Au bilan de cette prose, j'ai mis beaucoup de choses sans preuve à l'appui, c'est du retour d'expérience personnelle sans métrique derrière, je n'ai pas le courage d'installer tout ce qu'il faut pour aller faire des comparaisons reproductibles.
    Peut-être que quelqu'un dira tout le contraire.

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

    Par défaut

    Citation Envoyé par Waldar Voir le message
    ...de surcroît il y a un bug sur les dirty read où parfois ça génère un doublon, même en lecture sur une table avec une P).
    Ce n'est pas un bug, c'est un comportement normal de la lecture sale...

    Citation Envoyé par Waldar Voir le message
    Dans un grand site de vente en ligne qui tourne, ils ont opté pour les dirty read, non pas par amour mais parce que les autres modes d'isolation ne font pas le job, soit à cause des verrous soit à cause des performances.
    Je dirais que c'est souvent par incompétence, car ils peuvent faire du verrou optimiste avec le niveau d'isolation SNAPSHOT. Cependant pour faire des camembert statistique une marge d'erreur de 2% ne sera pas visible...

    Citation Envoyé par Waldar Voir le message
    Donc oui pour revenir aux hints, l'utilisation des dirty read se faisait en précisant à chaque appel de vue / table dans tous les scripts, fonctions et procédures, un petit (read uncommitted) systématique. Ça fait pas mal de rajouts de hint in fine.
    La encore incompétence, car il n'est pas nécessaire de rajouter cela dans la requête. À mon sens le SQL des requêtes ne devrait JAMAIS être touché par le rajout des options physiques. Cela peut être fait :
    1) en optant pour le niveau d'isolation READ UNCOMMITTED soit dans le batch qui lance la requête, soit dans la connexion.
    2) en interceptant la requête dans le serveur SQL avant exécution et en rajoutant dynamiquement le hint à la volée (guide plan de requête).

    Côté R-OLAP, l'optimiseur d'Oracle va commencer à pêcher sur des requêtes de plusieurs milliers de lignes (la requête, pas le contenu des tables).
    SQL-Server est très vite à la ramasse. Les jointures avec beaucoup de colonnes ont des performances moins bonnes qu'en calculant un hash de toutes les colonnes, en gardant à l'esprit les problèmes inhérents aux hashs.

    Les requêtes avec beaucoup de niveaux, idem SQL-Server est poussif.
    En général sur Oracle on lance une grosse requête, là où sur SQL-Server il vaut mieux créer plein de tables temporaires pour stocker les résultats intermédiaires, justement pour palier la faiblesse de l'optimiseur de SQL-Server.
    Alors oui, on met des hints sur Oracle pour changer ci ou ça, mais y'a pas photo au final, on bricole moins à écrire quelques hints qu'à réécrire tout un traitement.

    Maintenant, les deux bases sont quand même très robustes et en général si on a l'une ou l'autre ça ne vaut pas le coup de migrer pour celle d'en face, sauf usage bien précis (typiquement, les DWH sur SQL-Server, c'est mauvais).

    Au bilan de cette prose, j'ai mis beaucoup de choses sans preuve à l'appui, c'est du retour d'expérience personnelle sans métrique derrière, je n'ai pas le courage d'installer tout ce qu'il faut pour aller faire des comparaisons reproductibles.
    Peut-être que quelqu'un dira tout le contraire.
    Moi j'ai l'expérience inverse, notamment avec les gens qui fuient Oracle et constate que SQL Server consomme moins de ressources et pour les grosses requêtes s'en tire incomparablement plus vite... Mais peut être n'as tu pas travaillé avec les versions récentes... pour information de grosses différences ont eut lieu avec les version 2012 et 2014. Sans parler des améliorations des version 2016 et 2017....

    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: 12
    Dernier message: 23/02/2016, 11h44
  2. Réponses: 0
    Dernier message: 19/04/2013, 13h20
  3. Réponses: 1
    Dernier message: 09/07/2009, 21h55
  4. Réponses: 2
    Dernier message: 25/05/2007, 15h58

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