1

Yo yop x)
Explications:

TABLE rankings
pseudo VARCHAR(64),
timestamp INT,
attaque INT,
defense INT,
general INT;


Bref, ça c'est la structure de ma table grin. C'es dur à expliquer mais je vais essayer.

En gros, chaque membre a plusieurs enregistrements. Seuls le timestamp, et les différents classements diffèrent.
Le truc, c'est que je veux récupérer deux et seulement deux élements en les triant avec les timestamp, en ne prenant que les plus récents. Mais je veux le faire pour tous les membres.

J'ai donc fouillé un peu et au trouvé les procédures stockées.

Je vous file la mienne :
CREATE PROCEDURE ListMembers()
BEGIN
	#SELECT pseudo FROM rankings IN pseudolist;
	DECLARE curseur CURSOR FOR SELECT pseudo, timestamp, attaque, defense, general FROM rankings IN pseudolist LIMIT 0,1;
	DECLARE var_pseudo VARCHAR(64);
	DECLARE var_attaque INT;
	DECLARE var_defense INT;
	DECLARE var_general INT;
	DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
	
	OPEN curseur;
	
	REPEAT
		FETCH curseur INTO var_pseudo, var_timestamp, var_attaque, var_defense, var_general;
		IF done=0 THEN
			SELECT var_pseudo, var_timestamp, var_attaque, var_defense, var_general;
		END IF;
		UNTIL done;
	END REPEAT;
	
	CLOSE curseur;
END;


Le truc c'est que je sens que c'est pas ça du tout, que j'ai pas MySQL là où je suis, et que, ben, c'est que je vois pas comment restructurer ma procédure ^^.

Une aide serait donc fort appréciable grin.

Bonne journée et merci d'avoir lu ce mini-pavé x)

2

j'ai pas le temps de tester là mais une requête sélect sur la table avec where timestamp in (un sous sélect sur la table where le pseudo est celui du premier sélect order by le timestamp limit 2) devrait faire l'affaire, non ?
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

3

BY timestamp LIMIT 0,2J'ai pas compris, mais SELECT * FROM rankings ORDER marchera sûrement pas :s

4

c'est pas du tout la solution qu'il a proposée (même si a priori elle devrait pas être très rapide non plus)

ceci dit je comprends pas le topic : quel est le problème, si je comprends bien tu n'as même pas essayé la solution du post ./1 ? btw tu devrais remplacer ton varchar(64) par un char(64) puisque tes autres champs sont constants, ça t'éviterait d'avoir une taille d'enregistrement variable et de perdre en perf pour pas grand chose smile
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

5

Je viens de découvrir les requêtes stockées, et je sais pas encore comment les extraire ... Je planche sur la structure de la procédure :s

6

putain, faut tout écrire en plus cheeky...

SELECT * FROM rankings a WHERE a.timestamp IN (SELECT timestamp FROM rankings b WHERE a.pseudo=b.pseudo ORDER BY b.timestamp LIMIT 2);

ou un truc du genre...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

7

Aux temps pour moi, j'apprends encore un truc grin. Désolé.

C'est pas lourd niveau ressources par contre ? C'est pas une bête de course mon serv (P2 512Mo RAM 40GoDD)

8

FireHunter (./7) :
C'est pas lourd niveau ressources par contre ?


C'est pas "lourd" à proprement parler, mais dans certains cas, ça peut être un peu plus lent comme le dit zephyr un peu plus haut
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

9

En passant, il est conseillé de lister explicitement l'ensemble des champs que tu veux récupérer avec ton SELECT. Ca sera toujours plus rapide qu'un SELECT * (le SGBD est obligé de faire une requête de structure pour récupérer l'équivalence de * en liste exhaustive)
avatar

10

Ouaip, j'ai trop pris l'habitude du * et ça me résupère des champs pas utiles

11

./9 : bof, c'est surtout pour des problématiques sécu que le "*" est à éviter, comme me disait vince à l'instant il doit plus rester beaucoup de SGBD qui s'amusent à lire la table de structure chaque fois qu'on utilise un "*"
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

12

Même sans lire la table des structures, ça veut quand même dire qu'il va consulter un index ou quelque chose comme ça... enfin, faudrait faire des bench cheeky
avatar

13

Je suppose que ça fait partie des informations en cache, et que le coût de consultation doit être vraiment négligeable par rapport à celui de n'importe quelle requête, même basique. Mais on peut toujours bencher ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

14

Ca sert à rien de bencher là dessus... de nos jours de plus en plus de projets utilisent un ORB qui fait lui même les requêtes de structure... (et souvent il les fait même si on n'en avait pas besoin)
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

15

Nil (./12) :
Même sans lire la table des structures, ça veut quand même dire qu'il va consulter un index ou quelque chose comme ça... enfin, faudrait faire des bench cheeky

À mon avis, tu as intérêt à avoir des *grosses* bases de données pour voir une petite différence hehe
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

16

Ca se limite à 25 personnes hein ^^. Un petit groupe de chanceux. Après, ça pourra monter à 150 x)

Bon, merci vince, j'vais regarder ça, et en attendant je vais faire un gros code dégueulasse et imbriquand deux while *sig* triso

17

Pour l'histoire de "select *" vs "select liste de champs", il y peu y avoir deux impacts, en dehors de ce qui est sécurité ou autre :

- select * signifie généralement plus de données retournées ; donc, plus de traffic réseau, et plus de mémoire consommée du côté de l'application
- un select sur quelques champs très précis peu être intéressant dans le cas où ces champs sont tous inclus dans l'index utilisé pour effectuer la recherche (du moins, dans le cas où la requête est suffisament bien foutue pour n'effectuer de recherche que dans un index) ; ça veut dire lire les données depuis l'index, qui a de fortes chances d'être en RAM, plutôt que d'aller chercher les données, qui ont des chances plus élevées d'être sur le disque -- du moins, en MySQL.
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall