Salut j'ai une colonne num_client où chaque client a un numero.
Je veux trouver le client qui a le plus grand numero et retourner ses autres attributs (par ex nom, prenom)
 
Avec max je trouve le num le plus grand mais impossible de retourner le reste de la ligne!
 
Si qqn peut m'aider
 
CHaiCA

elle ressemble a koi ta requete?

Faut ruser.
Au lieu de chercher le max de la colonne, trie la par ordre décroissant et ne garde que la première ligne

OUAH merci de répondre! VOila ma requete :
 
select num_users, nom_users, pws_users from users_site where num_users = (SELECT MAX(num_users) from users_site);
 
Pourquoi ca passerait pas?  
Si je pars dans une autre optique et que je trie en decroissant ,cOmment tu fais pour ne garder que la premiere ligne sous mysql?
 
CHaiCA

peut etre supporte t il mal les requetes imbrikées, essai de passer par une variable tampon et de les dissociées.
 
concernant la recuperation juste de la premiere: si tu lis avec un while, vire le while et fait kune lecture a la premiere ligne du tableau.
 
cependant je te deconseille cette methode meme si elle parait seduisante de loin: meme si tu lis ke la premiere ligne, tu charges tout la tables en memoire, ce ki n'est pas forcement une bonne idée..
 
ressai ta methode en passant par une variable tampon

Leirn : ouais je vais essayer ca mais je suis un peu decu si mysql gere si mal les requetes imbriquees, m'enfin c'est gratuit, on peut pas tout avoir.
 
Toutefois pour recuperer la premiere ligne tu peux normalement faire ca dans la requete meme par exemple sous sqlserver, c'est top 1 apres avoir trier en decroissant.
 
Bon pour l'instant je vais essayer le tampon on verra bien
 
Mais si quelqu'un a une autre soluce je reste preneur!
 
CHaiCA

Je ne crois pas que mysql gère les requêtes imbriquées  
 
Pour garder la dernière ligne, tu rajoutes "LIMIT 0, 1" à ta requête (0 car tu prends la première ligne (numérotées à partir de 0), et 1 pour le nombre de lignes que tu veux récupérer).

 
effectivement si tu peux limiter le nombre de lignes renvoeyer a 1 (ce ki est posisble maintenant ke tu le dis, j'y avais pas penser tout a l'heure, le tri c ce kil y a de plus mieux
 
 
en revanche, c absolument normal kil gere pas les requetes imbrikés... contrairmeent a du c ou tu peut avoir kke cose de la forme
 
for (i=0; i<foncitonkirecuepereunchiffre(); i++)
 
le sql foncitnone sous forme de requete et non pas d'appel de fonction

Leirn : heu... oracle les gere parfaitement (tested and approved everyday)
 
CHaiCA

chaica a écrit a écrit : Leirn : heu... oracle les gere parfaitement (tested and approved everyday)   CHaiCA

 
je ne sais pas comment fonctionne oracle jamais essayé

mysql gere les subqueries uniquement a partir de la version 4.1 qui est en cours de developpement

Ex :
 
 

 
les subqueries c les requetes imbriqué?

oui

Et t'as aussi les derived table :
 
SELECT * FROM (SELECT truc FROM pouet WHERE schmeu) WHERE gloups=hummf;

et elle sort bientot la v 4.1 ? et pourkoi ils ont pas fait ca avant?

parce que c'est pas trivial a faire

 
ha ok    
 
sinon on fait comment pour remplacer cela car ca a l'air tres utile

jointure, requete fait en deux fois, etc

 
ok  

Elle n'est pas conçue bizarrement ta DB ?
 
Le stockage du pseudo de l'auteur en lieu et place de son ID n'est pas commum. Ca fait perdre de la place et c'est peut être pas le mieux niveau relationnel si ? Tu es vraiment gagnant avec la jointure que ca te fait économiser ?
 
Autre point curieux : on dirait que tu créés une table par forum (table forumconthardwarefr7 pour le forum Blabla - Divers qui porte le n°7). Tu as constaté un gain de performance significatif en procédant ainsi plutôt qu'en créant une table commune avec un champ indexé forum_id ? Ca semble assez déroutant comme organisation

il supporte les jointures entre la requête principale et la requête imbriquée ?
 
Par exemple, pour récupérer le dernier post de chaque membre :

Si oui, alors mySQL va peut-être enfin devenir intéressant...

Il utilise le login comme clé.
C'est pas plus lent, ça bouffe pas beaucoup plus de place, et ça évite de faire des jointures sans arrêt pour retrouver le pseudo de l'auteur.

Et, dernière question, supporte-t-il les requêtes dans le select ?
 

C'est qu'il répondrait pas ce Joce

réponse : oui
D'ailleurs t'es pas obligé de rajouter FROM DUAL