Reprise du message précédent :
je parle d'arjuna, dont je trouve le comportement vraiment très désagréable, hautain et fier, je n'aime pas du tout ce genre d'attitudes...
enfin nous ne sommes pas là pour faire de la psychologie  

Enfin Arjuna aide quand-même pas mal de monde ici

 
N'empeche que chacune des interventions d'Arjuna est riche pour tous.
Je pense que en matière de BDD c'est un des meilleurs forumeurs.
 
 

 
Oui tout à fait.

 
Ben non. D'une part parce qu'il y aura toujours une différence infime, et quelque soit le sgbd, parce que l'optimiseur doit se palucher une requête écrite par un âne avec de gros sabots et d'autre part parce qu'un optimiseur n'est pas là pour réécrire correctement n'importe quoi. Faut dire que c'est de la pure philosophie microsoft votre histoire: "un produit est une bouse s'il ne sait pas corriger les âneries de l'utilisateur (bref, s'il n'a pas été conçu pour des ânes)"

 
Il sert à quoi alors?

 
A trouver le meilleur plan d'exécution.

 
 
Donc il peut avoir à réécrire la requête.
 
Edit: http://forum.hardware.fr/forum2.ph [...] ash_post=0

 
Groumf
 

 
Comme disait l'autre, ce sont des bouses...

 
Question de point de vue...

Moi j'aime bien quand je sais ce que je fais avec mon outils. Que l'ordre des tables dans la clause forme impacte le plan d'éxécution est extrêment important au cas où l'optimiseur n'arrive pas à trouver lui-même les meilleurs index notamment : on peut le forcer à scanner les tables dans un ordre précis, et ainsi garantir un temps de réponse toujours correct même si les stats ne sont plus à jour.
 
Par contre, je n'aime pas quand mon outils ne comprends pas ce que je fais. Demander les nombres pair et impair dans une même requête, c'est normal qu'il comprenne tout seul comme un grand qu'on veut tout.
 
Ensuite, un autre petit exemple que j'ai donné à un développeur de ma boîte ce matin :
 
"select count(*) from latable where champ like '%s%'"
=> full scan de la table
 
"select count(*) from latable where 1 = 1"
=> lecture de la PK uniquement
 
"select count(*) from latable where 1 = 1 or champ like '%s%'"
=> lecture de la PK uniquement
 
"select count(*) from latable where champ like '%s%' or 1 = 1"
=> lecture de la PK uniquement
 
Ben je trouve ça intéressant que SQL Server s'occupe de faire les tri les plus faciles en premier, avant de passer à ceux qui mettent deux heures. Ce n'est pas le cas de tous les SGBD.
Il faudrait voir comment se comportent Oracle et MySQL. Oracle, à priori, je n'ai jamais eu de changement de perfs quelque soit l'ordre de mes critères de filtres. MySQL, jamais testé.

 
C'est sûr qu'avec un truc qui se vautre lamentablement, il vaut mieux pouvoir le forcer à ne pas se vautrer. Après, y voir un argument en la faveur du truc qui se vautre lamentablement, hrum...
 

 
Non, il n'y a rien de "normal" à ce qu'il doive comprendre que vous lui racontez n'importe quoi. Qu'il le fasse tant mieux sinon, ça obligera le développeur à réfléchir à ses requêtes.
 

 
De toute façon, il n'y a pas à tortiller du cul pour chier droit: à chaque bench (illégal) où apparaîssent MySql, Oracle et SQLServer, Oracle et MySql se battent en tête en laissant la daube de krosoft loin derrière

ben on regarde pas les même benchs. moi, ceux que je vois, oracle et sql server sont au coude à coude, alors que mysql n'est même pas testé, ne supportant pas le nécessaire pour être évalué avec le même bench.

ça pourrait être intéressant que chacun se justifie avec des URLs montrant des benchs "récents" (c'est évident)
 
au moins on apprendrait qqch qui ne tiendrait pas du "sqlserver c'est mieux" "non mysql c'est mieux"

mysql n'est même pas dans la course comme SGBD sérieux, manque trop de choses.

il manque quoi par exemple ?
Merci de vous JUSTIFIER par des sources précises...

 
Juste comme ca, tu as regarder les nouveux apports pour SQL Server??
Requête sur XML(intégration XPath et XQuery), P/S en .NET,......je pense que rien qu'avec ça, ca suffit à enterrer MySQL.
Et ne crois pas que je suis contre MySQL puisque je travail avec. Donc je sais de quoi je parle aussi.

heu.. là on parle de ce qui manque à mysql pour prétendre accéder, car il semble ne pas pouvoir, à la hauteur (relative) des concurrents, et tu sors que sqlserver intègre XPATH ?? euh :-D  
je dis pas que c'est inutile, mais ce n'est pas LA fonctionnalité ultime quand même. C'est surement très bien (tu peux montrer un exemple d'ailleurs stp ?), mais ce n'est pas le genre de choses que les autres posteurs critiquaient je pense.  
 
Moi je voudrais bien savoir ce qu'il manque à mysql pour qu'il n'ai plus cette réputation de sgbd tout pourri que les gens (qui pètent plus haut que leur cul) lui donne volontiers.
 
Merci de me citer les fonctionnalités IMPORTANTES qui lui manquent (il y en a surement mais je n'ai pas connaissance).

jusqu'a y a pas longtemps les vues et les triggers , ils devaient etre implementes dans la version 5.0.X je ne sait pas si c'est le cas

c'est pas encore parfait mais ça fonctionne
http://dev.mysql.com/doc/mysql/en/triggers.html
 
http://dev.mysql.com/doc/mysql/en/views.html
 
dans quelques semaines/mois ce sera à la hauteur des concurrents je pense..
aux spécialistes, que font les concurrents dans ces domaines que mysql ne fait pas encore ?

 
Oracle n'est absolument pas sensible à l'ordre des tables depuis la 8i avec l'avénement du CBO (Cost Based Optimizer) basé sur des statistiques calculées sur les tables et indexes à contrario du RBO (Rule Based Optimizer) basé sur des régles strictes dont l'ordre des tables.
 
Je serait très surpris que SQL Server n'est pas également évolué en ce sens

 
t'as des sources parce que moi j'ai toujours vu MySQL à la ramasse sur les gros volumes
 
Ce n'est pas une grande étude mais ça me parait confirmer mes lectures :
http://www.developpez.net/forums/v [...] sc&start=0
 
A choisir un SGBD alternatif, PostgreSQL est bien plus prometteur et complétement gratuit
MySQL est payant dés lors qu'il est inclus dans une appli payante

 
sauvegarde à chaud et clustering par exemple

Bon, je ne connais pas tout ce que fais MySQL, mais des trucs importants (outre le clustering et le backup à chaud en effet), moi je vois ça. (certaines sont peut-être déjà intégrées dans MySQL, mais je doute que la plupart le soient)
 
- Liaisons multi-base
- Liaisons multi-serveur
- Liaisons multi-sgbd (peux-tu faire une jointure entre un table MySQL et une table Oracle directement depuis MySQL ? Avec SQL Server on peut, Oracle très certainement aussi)
- Transactions imbriquées (faut commencer par le commencement)
- Transactions distribuées
- Scripts de transformations de données multi-sources (ensemble des 3 permettant d'importer/exporter des données sans se prendre la tête à faire un programme rien que pour ça)
 
Ca, ça me semble être les points les plus utilisés et les plus importants.
Pour les points 3, 5 et 6, je suis certain que MySQL ne les supporte pas (le 5 avec un peu beaucoup de chance)

Ca fait 2 ans (peut-être même plus) que Joce a posté les résultats de ses premiers tests avec des PS. Vu à quel point ça semble avoir évolué, je doute grandement que d'ici "quelques semaines" (à partir de 50 on peut toujours dire "quelques" ?) ce soit au point.

Le souci, c'est que les stats, c'est fait pour pas être à jour
 
SQL Server, en temps normal, est certainement très peu sensible à l'ordre des tables.
Mais récemment encore, je me suis retrouvé à diviser le temps d'éxécution d'une PS par 20 parceque j'ai changé l'ordre des tables dans une requête.
 
Il faut dire aussi qu'en plus, vu que c'était une PS, le plan étant calculé une fois pour toute, je ne pouvais plus rien gagner même après une maj des stats. Après correction de ce truc, j'ai pas cherché à faire des tests plus aboutis.

 
Charge au DBA de faire le nécessaire... un petit job et basta
 

 
Sous Oracle ça peut également arriver simplement parce que le nombre de permutation n'est pas infini. Il est paramétrable mais un nombre trop grand risque fort de générer un parsing TREEEEEESSSS long sur les requêtes complexes. Mais heureusement, il existe les hints pour "forcer" un plan d'exéctution ou les vues pour simplifier les requêtes et aider l'optimiseur à s'y retrouver

 
Dans ces cas-là, une fois la maj des stats faite, il suffit de recompiler la ps pour que le plan soit recalculé.

sous SQL Server le plan est calculé à la compil... pas à l'exécution ? Etrange...

 
google: mysql cluster.

 
c'est bien mignon ce genre de bench mais ça ne veut rien dire. Dans le même genre, j'avais réussi à faire tourner un sybase 5 fois plus vite sur un celeron 400 en ide que sur un athlon 1400 en ultra-wide (en optimisant la config du celeron pour mon bench et en laissant celle par defaut sur l'athlon...)

 
au temps pour moi, je parlais de partitionnement des tables qui te permet de séparer physiquement les données d'une même table selon un critère technique ou fonctionnelle : par année ou tous les millions de lignes par exemple
 
Cela améliore énormément les perfs dans les gros volumes
 
Pour le comparatif, je suis d'accord avec toi mais là c'est sur même machine et à config égale c'est plus intéressant que ce que tu avais fait même si c'est loin d'être ultra rigoureux

sur MySQL en particulier : http://sqlpro.developpez.com/cours [...] niques/#L9
 

 
Ah d'accord, ça s'appelle (appelait?) de l'horizontal splitting cette technique-là
 

 
ben faudrait surtout qu'il donne la config de ses serveurs, de ses bases, de ses tables, de ses indexes, ..., parce que comme ça, on peut pas en tirer grand-chose (pour ne pas dire rien).

peu importe justement de la config... on s'en fout de ce qu'il a, l'important c'est de comparer tous les SGBD sur la même
 
Bon, après évidemment, s'il alloue 2Go de mémoire à Oracle et 200ko à MySQL il va y avoir un problème

 
Le SQL et les SGDB ne m'interressent pas, mais selon toi on devrait fermer le CNRS, arrêter la recherche fondamentale, licencier tous les ingés & chercheurs de toutes les boites de part le monde...
 
à la base, toute R&D ne garanti pas retour sur investissement...... et beaucoup de projets finissent à la benne, certainement que pour tout le monde (hi-tech, physique, médical... ), y'a ptet même que 10% des projets amorçés en R&D qui s'avèrent viable (mais qui profitent du retour de savoir sur les projets non viables)....

 
Ben oui, c'est le but d'une PS, c'est pareil sur tous les SGBD : le plan est calculé au moment de la compilation de la PS, pas à l'éxécution. C'est d'ailleurs là dessus qu'une PS est plus rapide qu'une requête classique : plan déjà connu, donc phase de parsing et d'optimisation ignorée à l'éxécution.

 
Ha non, c'est pas pareil pour tout les SGBD. Oracle ne parsent pas les requêtes si on réexécute la même ou qu'on utilise les techniques appropriés (CURSOR_SHARING et/ou bind variable) mais si la requête change ou simplement si ça fait trop longtemps qu'elle est pas exécuté elle est à nouveau parsée. La procédure stockée ne permet que de centraliser le code et n'a aucun intérêt en terme de perf, une requête reste une requête, qu'elle soit lancé dans une vue, une proc stockée ou directement sous SQL*Plus ET HEUREUSEMENT.
 
J'imagine même pas recompiler les milliers de procédures, fonctions ou packages d'une appli à chaque collecte de statistiques
 
Franchement là vous me surprenez... je trouve ça TRES étrange comme comportement... Donc si vous créez un index sur une table il faut recompiler toutes les procédures qui appellent cette table pour que l'index soit pris en compte ?

Pas d'accord, un bench, pour être validable doit répondre à l'un des deux cas suivants :
-> AUCUNE optimisation : install classique, et basta.
-> Optimisation suivant UNIQUEMENT ce qui est décrit dans le white paper d'optimisation que fourni l'éditeur.
 
EN AUCUN CAS un DBA doit toucher à une base qui va servir à un test, parceque si un DBA connait bien un SGBD, il ne les connait pas tous, donc les optimisations seront inégales d'une machine à l'autre, donc le bench sera biasé.
 
Les deux benchs validables permettent de tester :
-> Les capacité du produit à s'adapter à une mauvaise optimisation, ainsi que les optimisation "générales" inclues dans les paramètres par défaut. C'est pas terrible comme bench, mais plus de 90% des produits sont utilisés comme tel, donc très représentatif.
-> Les capacités de l'éditeur à fournir des documentations complètes et pertinantes quant à l'utilisation de leurs produits, ainsi que les paramètres "courants" d'optimisation.
 
A chaque fois que j'ai pu voir un bench sur des "vrais sites" (pas un truc fais au fond de sa cave sur un portable overclocké), c'était en suivant ces critères.
 
A noter un très bon site effectué à la demande de Microsoft comparant SQL Server, Oracle, DB2 et MySQL, couplés aux environnement PHP, Java, .NET et programme compilé, reprenant l'exemple "Pet Shop" (exemple classique fourni dans toutes les documentations de Microsoft, qui est une petite boutique en ligne).
 
Les résultats étaient sans appel (sans parler de l'environnement) :
MySQL très rapide dans les tests préliminaires (peut de charge)
Oracle et DB2 étaient les plus à la ramasse dans ces deux cas (moteurs trop lourd pour des petites requêtes)
 
Avec montée en charge (10 000 commandes/consutlation du catalogue par seconde avec 1000 connections concurrentes pendant une heure), Oracle et SQL Server étaient au coude à coude, puis DB2 et enfin MySQL qui n'a pas validé les derniers tests (dépassement de la capacité de charge et éffrondrement du serveur).
 
Les tests étaient effectués selon des documentations préconisées par les éditeurs en fonction du bench. Ca fait un moment que ce bench est sorti, on peut peut-être encore le trouver sur le site de la MSDN (c'est là que je l'avais trouvé à l'époque).
 
A la défense de MySQL, ce teste date de 2002 ou 2003, et MySQL a pas mal évolué depuis.
Si les souvenirs sont bon, on pouvait télécharger les documentations fournies par les éditeurs pour l'installation/optimisation de leurs produits. Je ne me souviens plus s'il y avait les sources de l'appli ou pas par contre.

 
Ben nan, on s'en fout pas de la configuration des serveurs (sous-entendu des serveurs de bdd, évidemment). Là, il ne donne même pas l'os, les versions utilisées, s'il fait tourner le client sur la même machine que le serveur, ... Bref; à mes yeux, ça ne vaut rien comme résultat.

SQL Server aussi sait faire de la réutilisation des plan d'execution. Mais je ne prends pas ce truc en compte, parceque dans la réalité, c'est très rare que tu exécute 25 fois la même requête, hors le buffer qui contient les plan est très limité, donc passé une dizaine de requêtes différentes à la suite, le sgbd ne se souvient plus des requêtes précédentes. Cette optimisation est selon moi inutile.
 
Par contre, Oracle tout comme SQL Server (et ça c'est SUR), compile le plan avant l'éxécution. Il le vérifie par contre lors de l'éxécution, et recompile le cas échéant si les tables utilisées on subit des changements. Comment ça marche exactement, j'en sais rien, je pense que dans le plan il garde un numéro de version interne des objets utilisés, et ce numéro change à chaque modification d'un objet, du coup il sait quand il dfoit recompiler.

comme tu veux... c'était juste pour info
 
Effectivement Arjuna, j'ai vu le même mais j'suis pas foutu de le retrouver
 
Il y a la question de reprise sur incident qui doit être prise en compte aussi... MySQL n'a pas l'artillerie de SQL Server ou Oracle