Il ne faut toutefois pas tomber dans le piège de la reproduction à l’identique. Prenons le cas des hints dans Oracle, par exemple. Cela permet à un DBA de modifier les plans d’exécution des requêtes écrites par les développeurs, sans toucher à l’application. Cela permet de corriger certains défauts de l’application, sans parler avec les développeurs, ce qui, au final, n’est pas forcément une bonne chose, car c’est une occasion perdue d’échanger avec eux, de les faire monter en compétence sur les sujets liés à l’utilisation de la base de données. Et puis, surtout, d’une version à l’autre de votre SGBD les hints peuvent changer de manière assez drastique, obligeant à revoir l’ensemble des requêtes arrangées.
Les grosses applications en entreprise sont basées sur SAP, SIEBEL, PEOPLESOFT (pour les plus connus) et sont très critiques, beaucoup de logiciels de niches sont développés par des startups et sont très critiques, beaucoup d'applications propres à une entreprise sont basées sur des frameworks qui génèrent le code SQL et sont plus ou moins critiques.
LE point commun de toutes ces applications : ON S'EN BRANLE DU SGBDR !
Donc aujourd'hui le strict minimum que doit apporter un SGBDR aux DBA, c'est de pouvoir ajouter des hints à la volée, interdire des plans, stabiliser un ensemble de plans & co. Ces entreprises (SAP étant une exception) ne vont pas faire beaucoup d'efforts et les startups n'en font presque pas voir pas du tout.
J'ai vécu un enfer avec une base spatiale (d'une startup) pour les réseaux ferrés en Oracle 9i, le CBO n'intervenait pas dans les requêtes spatiales (le plan était produit uniquement à partir d'heuristiques), il fallait donc les aider avec des hints, mais en 9i seul les développeurs pouvaient les ajouter ! Et ils nous ont menés en bateau pendant des mois et n'ont jamais rien fait. Aujourd'hui j'aurais pu résoudre, je pense, les problèmes de performance avec les outils disponibles.
Il faut arrêter avec ce pseudo dialogue avec les développeurs, il existe très peu et est juste parfois impossible à cause des outils utilisés.
Aujourd'hui ont (les DBA mais tout type d'administrateurs) gère des parcs de 100 à 2000 serveurs de productions avec j'aimais plus de 18 DBA, on est évalué sur le temps passé à résoudre un problème pas à discuter avec les équipes de devs. Le SQL et le SGBDR ne sont pas le langage et outil préférés (ou maîtrisés) des développeurs. Beaucoup voient un SGBDR comme un système de fichier portable (d'ailleurs sur ce site de nombreuse dépêches et commentaire vont dans se sens). Donc le jour ou les écoles (peu importe le niveau) enseigneront les principes fondamentaux comme les transactions (résumées par ACID), ce qu'est une 3NF et le W.A.L modes cela pourra peut-être évolué, mais pour l'instant c'est le SGBDR qui s'adaptent aux pratiques majoritaires des développeurs et à leur déchargent chaque SGBDR va se comporter différemment (le CBO ne serra jamais parfais) ! Donc c'est aux SGBDR de fournir des outils pour adapter le code, le dév ne pourra pas faire une version par SGBDR.
# N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à -2.
Les grosses applications en entreprise sont basées sur SAP, SIEBEL, PEOPLESOFT (pour les plus connus) et sont très critiques, beaucoup de logiciels de niches sont développés par des startups et sont très critiques, beaucoup d'applications propres à une entreprise sont basées sur des frameworks qui génèrent le code SQL et sont plus ou moins critiques.
LE point commun de toutes ces applications : ON S'EN BRANLE DU SGBDR !
Donc aujourd'hui le strict minimum que doit apporter un SGBDR aux DBA, c'est de pouvoir ajouter des hints à la volée, interdire des plans, stabiliser un ensemble de plans & co. Ces entreprises (SAP étant une exception) ne vont pas faire beaucoup d'efforts et les startups n'en font presque pas voir pas du tout.
J'ai vécu un enfer avec une base spatiale (d'une startup) pour les réseaux ferrés en Oracle 9i, le CBO n'intervenait pas dans les requêtes spatiales (le plan était produit uniquement à partir d'heuristiques), il fallait donc les aider avec des hints, mais en 9i seul les développeurs pouvaient les ajouter ! Et ils nous ont menés en bateau pendant des mois et n'ont jamais rien fait. Aujourd'hui j'aurais pu résoudre, je pense, les problèmes de performance avec les outils disponibles.
Il faut arrêter avec ce pseudo dialogue avec les développeurs, il existe très peu et est juste parfois impossible à cause des outils utilisés.
Aujourd'hui ont (les DBA mais tout type d'administrateurs) gère des parcs de 100 à 2000 serveurs de productions avec j'aimais plus de 18 DBA, on est évalué sur le temps passé à résoudre un problème pas à discuter avec les équipes de devs. Le SQL et le SGBDR ne sont pas le langage et outil préférés (ou maîtrisés) des développeurs. Beaucoup voient un SGBDR comme un système de fichier portable (d'ailleurs sur ce site de nombreuse dépêches et commentaire vont dans se sens). Donc le jour ou les écoles (peu importe le niveau) enseigneront les principes fondamentaux comme les transactions (résumées par ACID), ce qu'est une 3NF et le W.A.L modes cela pourra peut-être évolué, mais pour l'instant c'est le SGBDR qui s'adaptent aux pratiques majoritaires des développeurs et à leur déchargent chaque SGBDR va se comporter différemment (le CBO ne serra jamais parfais) ! Donc c'est aux SGBDR de fournir des outils pour adapter le code, le dév ne pourra pas faire une version par SGBDR.