[MySQL] IF et produits de champs

[Holy]

Voici un exemple:

Code :

    SELECT SUM(u.power*b.number) as numb, b.state
    FROM battalion_tbl b
    LEFT JOIN player_tbl as pi
    ON pi.id = b.player
    LEFT JOIN unities_tbl as u
    ON pi.nation = u.nation AND u.pattern = b.pattern
    WHERE b.state != 'HER' AND pi.coalition = 'lumiere'
    GROUP BY b.state
    HAVING numb > 0

A priori, je vois pas trop comment je pourrais faire mieux ^^'

[Allwise]

Non Keke, ma modestie est telle que je ne choisirais pas un pseudo pour mettre en avant quelque capacité intellectuelle :p
Ça vient des pays nordiques et le sens se rapproche de "tous les vents"

Pour rester dans le sujet et puisqu'on parle de jointures, si tu donnes ta requête, donne aussi la structure des tables concernées, avec les clés et index.

[Holy]

Code :

CREATE TABLE IF NOT EXISTS `battalion_tbl` (
  `state` varchar(3) NOT NULL DEFAULT 'HER',
  `player` int(11) NOT NULL,
  `pattern` varchar(20) NOT NULL,
  `number` int(6) NOT NULL DEFAULT '0',
  PRIMARY KEY (`state`,`player`,`pattern`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;


CREATE TABLE IF NOT EXISTS `unities_tbl` (
  `nation` varchar(10) NOT NULL,
  `pattern` varchar(15) NOT NULL,
  `power` int(2) NOT NULL,
  `place` int(3) NOT NULL,
  PRIMARY KEY (`nation`,`pattern`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

J'avais oublié de mettre des index sur la table unities_tbl (trop pressé). C'cool j'ai gagné deux fois le temps de traitement (0.022 à 0.0110).

unities_tbl est en MyISAM vu que je n'y ai accès qu'en lecture. Pas d'index autre que des clés primaires doubles et triples selon la table. Je vous ai pas mis player_tbl étant donné qu'il n'y a que le champ nation qui nous intéresse.

[Allwise]

Ça m'a l'air tout bon, je vois pas comment tu pourrais optimiser davantage non plus ( j'avais pas vu ton message précédent ).
Sinon, pour t'assurer que tes requêtes sont optimisées, tu peux précéder ta requête de la commande EXPLAIN. Ca te dira combien d'enregistrements sont parcourus pour ta requête principale et les requêtes sous-jacentes qui viennent des jointures et des requêtes imbriquées. Une arme fatale contre les oublis d'index

[keke]

Hum

Code :

WHERE b.state != 'HER' AND pi.coalition = 'lumiere'

je me demande si l'usage de texte n'est pas plus lent que l'usage d'identifiant.

Si tu avais défini coalition dans une table et que 'lumiere' aurait l'id 1, tu pourrais changer ta table player pour utiliser un TINYINT au lieu d'un VARCHAR.

Il me semble qu'il faut le plus souvent passer par des tests de conditions par ID que par valeur littérale ...

Bon, c'est peut-être pas le but de se prendre la tête pour des pouièmes de secondes ^^

kéké

[Holy]

Y a aussi la question de la lisibilité ^^
Personnellement j'préfère des valeurs littérales qui m'en disent plus que des int qui me poussent à chaque fois consulter ma doc si je veux agir en db ou autre ^^

Cela dit, tu n'as pas tort

[Ter Rowan]

Y a aussi la question de la lisibilité ^^
Personnellement j'préfère des valeurs littérales qui m'en disent plus que des int qui me poussent à chaque fois consulter ma doc si je veux agir en db ou autre ^^

c'est vraiment pas faux ^^

j'ai choisi d'utiliser des int pour les clefs mais alors...

savoir que

10 / 3 / 6 / 1 / 12 / 30 / 5 / 80

veut dire que pour créer une compote de pommes il faut 3 kilos de pommes et utiliser la compétence "cuisine" avec un bonus de 30 le tout pour 5 minutes de préparation et 80 de cuisson, c'est d'un chiant ^^

[keke]

compte de pomme/ 3 kilos/cuisine/bonus + 30/recette/ingrédient/5 minutes/1h et 20 minutes/

c'est pas mieux présenté que :

10 / 3 / 6 / 1 / 12 / 30 / 5 / 80

Dans tous les cas, faut des fonctions pour présenter les choses. Mais j'ai compris l'argument de feignant ^^ t'inquiète !

Kéké

[jo_link_noir]

Y a enum aussi, j'pense que c'est un bon compromis entres les 2. J't'dit ça mais j'utilise un TINYINT ^^