Discussion :

[Dragonflash]

Bonjour,

Je possède deux tables. L'une contenant des news et l'autre permettant de savoir si un administrateur a vu ou non la news.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
CREATE TABLE `news` (
  `id` int(11) NOT NULL auto_increment,
  `user_id_posteur` int(11) NOT NULL default '0',
  `Message` text NOT NULL,
  `Titre` varchar(50) NOT NULL default '',
  `SourceNom` varchar(105) NOT NULL default '',
  `SourceUrl` text NOT NULL,
  `Date` int(11) NOT NULL default '0',
  `nb_vu` varchar(40) default NULL,
  `concerne` varchar(255) NOT NULL default '',
  `last_modif` int(11) NOT NULL default '0',
  `user_last_modif` int(11) NOT NULL default '0',
  PRIMARY KEY  (`id`)
)
 
 
CREATE TABLE `news_admin` (
  `user_id_admin` int(11) NOT NULL default '0',
  `news_id` int(11) NOT NULL default '0',
  `etat` int(11) NOT NULL default '0'
)

Le but est le suivant :

- Si une nouvelle news est entrée dans la table news, je pourrai être averti car il n'y a pas d'infos dans news_admin correspondant à l'id de la news ajoutée.
- Pour noter comme vu une news, il suffit d'ajouter dans la table news_admin l'id de la news avec l'état '1' (j'ai arbitrairement choisi 1).
- Lorsqu'une personne modifie une news, il suffit de mettre les champs etat à '2' pour la news correspondante.

Je souhaite à présent afficher toutes les nouvelles news et les news modifiées pour l'administrateur numéro 2. Il y a une nouvelle news et une news modifiée pour cet admin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
SELECT n.id, n.Titre, n.last_modif, a.etat
FROM news_admin a
       RIGHT OUTER JOIN news n
              ON a.news_id = n.id
                     AND a.user_id_admin = 2
 
1 905 total, traitement: 0.1533 sec
> 1903 etat à 1
> 1 etat à 2
> 1 etat à NULL
 
 
SELECT n.id, n.Titre, n.last_modif, a.etat
FROM news_admin a
       RIGHT OUTER JOIN news n
              ON a.news_id = n.id
                     AND a.user_id_admin = 2
WHERE etat = 2
 
1 total, traitement: 0.0039 sec
> 1 etat à 2
 
 
SELECT n.id, n.Titre, n.last_modif, a.etat
FROM news_admin a
       RIGHT OUTER JOIN news n
              ON a.news_id = n.id
                     AND a.user_id_admin = 2
WHERE etat = 2 OR etat IS NULL
 
2 total, traitement: 10.2352 sec
> 1 etat à 2
> 1 etat à NULL

J'arrive effectivement avec la dernière requête a extraire la news ajoutée et la news modifiée, mais le temps de traitement est de 10 secondes !

Si j'utilise la première requête et que je fais le tri des résultats en php (c'est-à-dire que je ne garde que les état NULL ou égalent à 2) c'est aussi très long.

Quelqu'un sait pourquoi cela prend autant de temps de tester simplement un IS NULL sur le champs etat ? Je ne comprends pas cet écart de temps de traitement...

[fsmrel]

Bonsoir,


Avez-vous exécuté un EXPLAIN afin de voir si le SGBD utilise les index de façon satisfaisante (s'ils existent) ?

Par ailleurs, avec un RIGHT OUTER JOIN, vous récupérez toutes les lignes concernées. Un test d'existence (WHERE ... EXISTS...) serait a priori plus économique.

Au passage, la table news_admin n'a ni clé primaire ni clés étrangères ?


N.B. Pour le confort des lecteurs, merci d'indenter les requêtes, comme cela est précisé dans la charte DVP :

la clause SELECT sur une ligne, la clause FROM sur une autre, etc.

[Dragonflash]

J'ai suivi votre conseil et ai ajouté une clé à la table news_admin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
CREATE TABLE `finaland_news_admin` (
  `user_id` int(11) NOT NULL default '0',
  `news_id` int(11) NOT NULL default '0',
  `etat` tinyint(1) NOT NULL default '0',
   KEY `i_userid_newsid` (`user_id`,`news_id`)
);

Voici à présent les temps de traitement pour les requêtes respectivements citées dans mon premier message :

1 905 total, traitement: 0.0040 sec.
1 total, traitement: 0.0107 sec
2 total, traitement: 0.0226 sec.

Me voilà sauvé, j'ai divisé par 500 le temps de traitement de la dernière requête (celle qui m'intéressait !)


Pour répondre à vos questions :

- J'ai trouvé un site qui explique comment faire un EXPLAIN, mais la création de la table a échoué. Je n'ai pas cherché plus loin dans cette voie.

- Pourriez-vous m'expliquer pourquoi un WHERE...EXISTS serait-il plus efficace qu'une jointure externe ?

- Toutes mes excuses pour l'indentation, je vais modifier cela de ce pas ^^

[fsmrel]

Bonsoir,

Me voilà sauvé, j'ai divisé par 500 le temps de traitement de la dernière requête

Sauvé, du moins pour cette fois-ci. Mais il n'est pas dit que pour d’autres requêtes, vous ne retrouviez pas à nouveau des problèmes de performance.

J'ai trouvé un site qui explique comment faire un EXPLAIN, mais la création de la table a échoué. Je n'ai pas cherché plus loin dans cette voie.

Je vous engage néanmoins vivement à étudier cette instruction, ne serait-ce que pour comprendre très vite pourquoi votre SGBD rame pour telle ou telle requête.

Pourriez-vous m'expliquer pourquoi un WHERE...EXISTS serait-il plus efficace qu'une jointure externe ?

En fait, EXISTS vaut pour la jointure interne. Quand vous posez la question suivante au SGBD : « Est-ce qu’il y a du courrier pour Tartempion ? » en utilisant la clause EXISTS, un SGBD normalement constitué dira une seule fois oui dès qu’il en aura trouvé et ne cherchera pas à pousser plus loin ses investigations. En revanche, avec la jointure, il dira oui, oui, oui, ... autant de fois qu’il trouvera du courrier. Maintenant, si vous voulez tout savoir sur chacun de ces courriers, vous joignez. Pour savoir objectivement quelle requête est la plus appropriée : EXPLAIN.

Concernant la jointure externe, le pendant est NOT EXISTS. En cas d'absence de courrier pour Tartempion, la réponse sera encore une fois unique, au lieu de redonder n fois. A nouveau, si vous voulez tout savoir sur chacun de ces courriers, vous joignez. Pour savoir objectivement quelle requête est la plus appropriée : toujours et encore EXPLAIN.


Et, beaucoup plus important, n’oubliez pas de définir les clés étrangères pour la table finaland_news_admin, afin de ne pas vous retrouver avec des références a des news et des users inconnus au bataillon.