pb de jointures (?) mysql - Page 2

oui, mais elle ne sert à rien dans mon cas

faut dire que le but, c'était d'avoir un truc qui tourne le plus rapidement possible, maintenant je peux chercher à optimiser ^^ (je m'en foutais un peu du temps de génération de chaque page)

On est pas obligé de mettre une clé primaire sous mysql

Ca doit être souvent le cas (on est pas obligé non plus sous Oracle).

je pense que c'est le cas partout, mais comme je ne connais pas tout les SGBD...

Ah ok, je découvre ça !

En fait si tu ne spécifies pas de clé, je crois que les SGBDR en créent une en plus de ta base, arbitraire et invisible. Par contre elle ne sert à rien niveau performances vu qu'elle n'est jamais utilisée.

Enfin, je dis ça mais je suis probablement un peu déformé par les bases Oracle du boulot qui sont plutôt performantes...

Faut voir sur quoi elle tourne aussi. Genre chez le client, les bases Oracle sont montées (en cluster mais c'est du failover donc ça affecte pas les performances) sur des quadriproc hyperthreadés cadencés à 3GHz, avec 32Go de ram et des hba load-balancés (20Gbps de bande passante théorique pour les accès disque).
Forcément les perfs sont pas tout à fait les mêmes que sur un pc perso.

spectras
:

Enfin, je dis ça mais je suis probablement un peu déformé par les bases Oracle du boulot qui sont plutôt performantes...

Faut voir sur quoi elle tourne aussi. Genre chez le client, les bases Oracle sont montées (en cluster mais c'est du failover donc ça affecte pas les performances) sur des quadriproc hyperthreadés cadencés à 3GHz, avec 32Go de ram et des hba load-balancés (20Gbps de bande passante théorique pour les accès disque).
Forcément les perfs sont pas tout à fait les mêmes que sur un pc perso.

bof, mon iBook 1.2GHz n'en est pas si loin

ça tournait 10x plus vite sur mon ibook 1ghz que sur le tiens en 1.2 ghz

sinon je croyais que mysql à partir de la 4.1 ne prenait pas en compte les sous requetes non ? ou alors j'ai revé

je me repond tout seul oui a partir de la 4.1 et memes les procedures stockes a partir de la 5 , hmm hmm faudrait que je me remette a jour sur mysql moi xD

et les trigger aussi récemment

A noter que ce n'est pas parce que c'est supporté que c'est forcément une bonne idée de l'utiliser.
Les triggers ont le potentiel pour ruiner les performances d'une base de manière plus ou moins aléatoire si un très grand soin n'y est pas apporté.

j'aimerais poser une question intelligente du même genre sur des requêtes complexes mysql mais d'abord je voudrais que vous compreniez bien que j'ai PAS suivi de cours sur les SGBD non plus (Ethaniel, viens pas me dire d'attendre )

j'ai une table avec un champ ID et un champ nom (contents)
1 blabla
2 blibli
3 bloblo

et une autre table avec des timestamp et des ID (events)
10:30 1
10:42 1
10:53 3
11:12 2

la requête nécessaire pour obtenir la réponse:
10:30 blabla
10:42 blabla
10:53 bloblo
11:12 blibli

c'est quel genre? en gros il me faudrait un "select timestamp from events (and à coté nom from contents where id=event_en_cours.id) where cequejeveux "
je soupçonne un JOIN quelque chose mais quelle syntaxe doit être utilisée? j'avoue que c'est un des rares trucs que j'ai pas réussi à apprenre tout seul

JE SUIS DESOLE si je demande la même chose que le précédent mais j'ai pas trop compris son optimisation donc je redemande!

(pour le moment j'ai un sale vieux workaround qui fait une requête à chaque ligne pour obtenir la donnée mais non.. ça tient pas la route pour plus de 10 lignes quoi )

je suis conscient que la réponse que j'attends doit être triviale quand on l'a étudié, mais je vous serais reconnaisants si vous vouliez me sortir de ma crasse temporaire

Ça marcherait pas ça ? (attention j'ai jamais vraiment fait de trucs compliqués en SQL)

select a.name, b.time from table1 as a, table2 as b where a.id = b.id

toutafait !
cf ./1 et ./2 ^^

j'aurais pas pu deviner, merci ^^

à noter que tu peux effectivement faire avec un JOIN comme tu supposais, je n'ai rien pour tester là mais je pense que ça ressemble à peu près à ça :

SELECT nom, timestamp FROM contents LEFT NATURAL JOIN events;

(en terme de perf, faudrait demander à qqun qui connait, il aurait fallu que j'écoute mes cours des sgbd pr pvoir répondre ^^)

Bof, ça doit être purement syntaxique.

NATURAL c'est un raccourci pour dire « joindre les tables par leurs clés primaires respectives », j'imagine ?

c'est comme si tu faisais "ON table1.a = table2.a AND table1.b = table2.b" (etc sur tous les champs qui ont le même nom, si je me souviens bien)

#48 > c'est très probable oui mais je préfere ne pas trop m'avancer ^^

ok C'est un peu dommage parce que si dans une table t'as un champ name qui a pas la même sémantique que le champ name d'une autre table, ben t'es baysé. :/

effectivement, mais faut réflechir à ça quand tu crées tes tables ^^ (bien sûr le type des deux champs qui ont le même nom doit être le même également)

au passage, en cherchant je viens de lire ceci, donc à vérifier à l'occasion :

Also Note: Both methods of joining tables should give the same results. The natural join is more CPU efficent on most SQL platforms.

(http://www.fluffycat.com/SQL/Join/)

Zephyr :
effectivement, mais faut réflechir à ça quand tu crées tes tables ^^ (bien sûr le type des deux champs qui ont le même nom doit être le même également)

Ouais c'est bien ce que je dis c'est chiant ça

Zephyr :
au passage, en cherchant je viens de lire ceci, donc à vérifier à l'occasion :

Oui, j'aimerais bien voir des chiffres.

A l'IUT on m'avait dit que dans le cas du JOIN, on avait des performances moins bonnes que dans le premiers cas...

Moi, on m'a dit que la jointure etait plus performante...
Ca doit pas mal dependre des sgdb je pense

Pour info : les proc stockées, c'est à utiliser au cas par cas selon les sgbd, avec oracle y'a moyen de déchirer sa reum niveau perf, avec sybase ou db2 c'est le meilleur moyen pour "simuler de la charge" si vous voyez ce que je veux dire

Les selects imbriqués, c'est à éviter quoi qu'il arrive

Le triggers, comme dit spectras, ça dépends c'est pour quoi faire... mais quand on voit que des gens font des requètes de furieux sur un trigger db_insert, ça fait peur (en gros l'insert dure 1 min au final :/)

Enfin, et c'est à méditer, les jointure, c'est spécifiques à chaque sgbd, certains vont aller plus vite avec (sybase, mssqlserver) et d'autres vont préférer les where clause monstrueuses (comme oracle par exemple)

Et les select en cascade... faut les garder pour les cas où on ne peut absolument pas faire autrement. (comprendre certains rares cas où il est indispensable que les deux critères soient checkés en deux moments distincts...

autre chose, entre un LIKE sur un champ texte et un = sur un champ numérique (quoique souvent il n'existe qu'un type physique identique mais c'est pas la question) il y a une différence palpable de temps de traitement, donc évitez les clés primaire sur le champ adresse ou n'importe quel champ texte conséquent qu'il faudra comparer alors qu'une valeur numérique associée à un index peut rendre la requète quasi instantannée

C'est vrai, de manière générale dès qu'il n'y a pas de candidat numérique, il vaut mieux créer un surrogate ^^

57> c'est dans l'esprit "nombre plus vite que texte" que j'ai séparé mes noms dans une table séparée en reniflant qu'il y avait un intéret, mais je me suis trouvé con pour les remettre ensemble dans le select, d'où ma question ^^

Ce topic est intéressant

Où en est mysql sur le plan de la performance comparée avec les autres? c'est étudié ou les entreprises s'en fichent?

je viens de tester

SELECT log.* , users.login
FROM log, users
WHERE users.id = log.userid
AND NOT (
TYPE = "info"
)

et
et en plus c'est vraiment moins dur que ce que je croyais. Il me manquait juste la syntaxe de FROM