Bonjour,
 
Je suis actuellement a la recherche de solutions pour effectuer un classement en PHP grace a des données de plusieures tables MYSQL : EX :
 
Table 1 -- champ NOM-z /champ points ==> 5
 
Table 2 -- champ NOM-e /champ points ==> 1
 
Table 3 -- champ NOM-a /champ points ==> 15
 
Table 4 -- champ NOM-w /champ points ==> 11
 
Table 5 -- champ NOM-x /champ points ==> 22
 
Je voudrais afficher dans ma page php
 
Chaque nom en ordre croissant en fonction des points... ICI:
Nom-x
Nom-a
Nom-w
Nom-z
Nom-e
 
 
En esperant avoir été clair Je remercie ceux qui prendront le temps de m'aider

Tu fais ta requête avec la clause "order by points DESC" à la fin

J'y ai pensé mais comme les données viennent de tables différentes sa ne peut pas fonctionner ?
Bonne journée et merci de ta réponse

ben gros malin, tu fais une jointure entre tes tables. Si on appelle ça "bd relationnelles", c'est justement parce qu'il y a des relations entre les tables, via les clés primaires et clé étrangères. Si ce que je raconte est du chinois pour toi, je te conseille de lire qq tutos sur les BD, parce que sinon, tu vas galérer grave pour faire les autres fonctions de ton soft

Je dirais qu'on est plus dans l'utilisation du "UNION" que de la jointure  
 
Un truc qui ressemblerait à ça :

oops, oui, j'avais pas vu les tables 1, 2, 3...
J'avais compris que les scores étaient dans une autre table... Encore une BD bien construite, ça, tiens

Salut et merci, ma Bd est très bien construite. Je n'ai pas qu'un classement a faire ne croit pas cela alros avant de critiquer irroniquement renseigne toi.
 
Je teste

Ben plusieurs tables qui contient un champ stockant une info de même nature, permets-moi de douter fortement que la BD est bien construite
 
Preuve en est, t'as eu du mal à écrire ta requête alors qu'avec une BD bien construite, généralement, l'écriture des requêtes se passe tout seul.

boarf, parfois c'est de l'optimisation justement que de separer une table en plusieurs.  
ca evite des problemes de deadlock en ecriture meme si ca rajoute un cout de consolidation.
 
apres de la la meme facon si tu n'as besoin que d'afficher les 10 premiers tu peux limiter les sub selects

 
deadlock en ecriture -> sur mysql, tables de type InnoDB et tu lockes plus une tbale entière comme c'est le cas en myisam
 
optimisation justement que de separer une table en plusieurs -> ça s'appelle le partitionnement, ça existe sur la plupart des sgbd. C'est un mécanisme complètement transparent (une table logique, plusieurs fichiers physiques) et tu partitionnes sur des colonnes ou lignes
 
afficher les 10 premiers tu peux limiter les sub selects -> order by + limit 0, 10 et une table bien indexée, ça fait l'affaire.
 
J'ajoute qu'en tunant le fichier de conf de mysql (principalement la taille des buffers et caches), tu peux grandement améliorer les perfs (à condition d'avoir de grosses requêtes sur des grosses tables, sur qq milliers d'enregistrement, ça se voit pas)

d'ou le "parfois"
 
je ne sais pas si il est en myisam ou innodb, mais j'imagine que si sa table est partitionnée logiquement c'est qu'il doit y avoir une raison.
en fait comme on connait pas vraiment ses contraintes c'est jamais evident.

 
D'expérience, une très large majorité des utilisateurs venant sur ce forum avec des questions sur des requêtes qui sont dures à écrire ou qui marchent pas ont leur BD mal conçue

Oui, je pense que quand on ne connaît pas le "UNION", il est peu probable que l'on maîtrise les avantages et inconvénients des tables partitionnées

ouep, ca arrive souvent que les requetes triviales posent probleme ici
 
mais ca veut pas forcement dire qu'il a la main sur le schema de la db.
 
tu peux souvent te retrouver avec une forme imposée ou l'on t'interdit de dénormaliser ou des cas ou les collations/encoding sont historiquement merdique (ahh la joie des tables en 8859-1 au milieu d'une base utf8 suite a une "consolidation" ) et ou tu en chies pour faire des trucs "propres" et ou ca rame a mort du coup

 
J'ai dit que sa BD était très probablement mal conçue mais en aucun cas que c'était forcément de sa faute. Je suis parfaitement conscient du poids que l'historique peut avoir sur une appli