Discussion :

[Kuriboh]

Bonjour,

Je suis bloqu� sur une commande pour extraire des donn�es de ma table.
D'habitude en fouillant et en bricolant je trouve la solution mais l�...

Voici ma table (avec des lignes en moins) :

id	val	val2	lum	date	time
1	71	120	0	20/08/2012	00:17:56
17	1000	30	0	21/08/2012	01:25:43
24	1000	111	0	21/08/2012	01:27:43
33	555	127	0	21/08/2012	06:09:07

Je souhaite afficher sur ma page les donn�es de la ligne avec "val = 1000" et ayant l'id le plus grand. Dans l'exemple ce serait id 24

Donc ma logique �tait d'identifier les lignes avec "val = 1000" et d'ensuite faire un MAX(id) mais sans succ�s.
J'ai test� quelques exemples trouv�s en ligne avec WHERE ou GROUP BY mais rien de fonctionnel.

Merci d'avance pour votre aide

[tatayo]

Bonjour,
C'est une question qui revient souvent.
escartefigue nous a fait un article qui donne 2/3 m�thodes: c'est l�.
L'article parle de "la ligne la plus r�cente", mais c'est la m�me chose.

Par contre attention, si l'id est attribu� automatiquement par MySql, rien ne garantit que l'Id le plus grand est celui de al derni�re ligne.

Tatayo.

[Kuriboh]

Bonjour Tatayo,

Merci pour l'orientation, quand on cherche avec les bons mots on trouve mieux.

Cette adaptation du code fonctionne dans mon cas.
Je tiens compte de la remarque sur l'utilisation de id dans ma recherche, je vais utiliser TIMESTAMP dans mon code final par s�curit�.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
SELECT val, val2, lum, date, time
FROM donnée
WHERE (val, time) IN (
	SELECT val, MAX(id)
	FROM donnée
	WHERE val = '1000'
)";

[CosmoKnacki]

Je m'interroge sur l'utilit� de s�parer date et time en deux colonnes plut�t qu'une seule colonne datetime.

[Kuriboh]

J'avais s�par� les deux donn�es pour pouvoir traiter plus facilement les donn�es relatives � une journ�es.
Mini, Maxi, Moyenne par exemple, vu que j'utilise �galement TIMESTAMP je pourrais me passer de l'heure et m�me de la date.
Mais je ne suis pas encore dans l'optimisation du code.

Finalement je pense abandonner cette m�thode car beaucoup trop gourmande en ressource.
Sauf si j'en trouve une autre plus int�ressante.

Je vais modifier l'�metteur des donn�s pour qu'il me pr�mache le travail.

[escartefigue]

Il existe des fonctions permettant d'extraire une partie (date, ann�e, mois, heure...) d'un timestamp. Donc il est tr�s facile de traiter une journ�e particuli�re � partir d'un timestamp.
Je n'ai pas compris quelle m�thode �tait "trop gourmande en ressources" ?

� propos d'optimisation, un test d'existence est tr�s souvent beaucoup plus performant en utilisant (NOT) EXISTS qu'avec (NOT) IN (subselect).
En effet, la deuxi�me solution construit tout l'ensemble des lignes correspondantes au pr�dicat, alors que la premi�re s'arr�te d�s qu'une ligne satisfait le pr�dicat.

[Kuriboh]

Bonjour,

Lorsque j'utilise le code suivant sur une BDD d'environ 12000 entr�e la page met plus de 30s � s'actualiser.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
SELECT val, val2, lum, date, time
FROM donnée
WHERE (val, time) IN (
SELECT val, MAX(id)
FROM donnée
WHERE val = '1000'
)";

[S�b.]

C'est tr�s long pour une table de 12k lignes.
Es-tu certain que le probl�me vient de la bdd ?
Comment as-tu fait tes mesures ?
Peux-tu nous communiquer le sch�ma de ta table et son contenu pour que nous testions ?
Des index ont-ils �t� pos�s ?

[tatayo]

Dans ta requ�te tu mets en relation une colonne "Time" et une colonne "Id".
Pour moi �a n'a rien � voir, un Id n'est pas une date/dur�e/heure�

Tatayo.

[escartefigue]

Outre la judicieuse remarque de Tatayo, v�rifiez aussi que la colonne val sur laquelle porte la restriction est bien de type CHAR ou VARCHAR, sans quoi, mettre la valeur entre quotes implique un transtypage implicite qui p�nalise les perfs en compromettant l'usage des index.

Une remarque : si le nom de la table est vraiment "donn�e", alors c'est un choix qui implique d'encadrer ce nom par des d�limiteurs (en standard, la double quote et pour MySQL/MariaDB la quote invers�e). D'une fa�on g�n�rale, on recommande d'�viter les noms r�serv�s et les caract�res sp�ciaux pour �viter ce genre de contingences.

[Kuriboh]

Merci pour vos conseils.
Je suis en d�placement jusqu'� fin de semaine donc je n'ai pas les �l�ments sous la main.
Je vous post �a en fin de semaine.

[Kuriboh]

Bonjour,

J'ai remis le nez dans le code et trouv� une autre solution beaucoup plus rapide

La structure de la base :

#	Nom	Type	Interclassement	Commentaire pour comprendre
1	id	int(10)
2	val1	float		valeur temp�rature
3	val2	float		valeur temp�rature
4	val3	float		valeur temp�rature
5	val4	float		valeur temp�rature
6	val5	text	utf8mb4_unicode_ci	Remonte un message
7	val6	text	utf8mb4_unicode_ci	remonte plusieurs type de message dont "demarrage"
8	maj	text	utf8mb4_unicode_ci	Timestamp
9	Date	date		sera supprim� � terme
10	Time	time		sera supprim� � terme

Resultat voulu: ligne la plus r�cente comportant le texte "demarrage" en prenant comme indicateur chronologique un TIMESTAMP sous forme de texte dans la colonne "maj"

Mon code definitif avec une nouvelle approche:

SELECT val1, val2, val3, val4, val5, val6, maj, date, time
FROM comble
WHERE val6 = 'demarrage'
ORDER BY maj DESC
LIMIT 1;

Cette requ�te remonte le m�me r�sultat que l'autre mais de fa�on presque instantan�e sur une base de 12k lignes
Le resultat me convient mais si vous avez des conseil je suis preneur.

Le but est totalement amateur pour un usage person totalement autodidact donc je t�tonne un peu (beaucoup)

Concernant le caract�re sp�cial dans "donn�e" c'est ma base pour les tests, mais effectivement je vais modifier suite au dernier conseil.

[escartefigue]

Le type FLOAT sert � stocker de tr�s grandes valeurs, c'est inadapt� pour des temp�ratures, sauf si vos sondes mesurent des temp�ratures � la surface des �toiles
Il faut savoir que le FLOAT provoque des pertes de finesse d�cimales, � remplacer par du type DECIMAL si la pr�cision est requise, voire par de l'INTEGER (�ventuellement SMALL suffira) s'il n'y a que des valeurs enti�res.
Par ailleurs, la structure de cette table n'est correcte que si chaque ligne concerne toujours 4 et seulement 4 mesures avec toujours 2 et seulement 2 messages.
Sinon, il faut une table avec une ligne par sonde et par mesure.

[Kuriboh]

Top, merci pour les conseils, je vais faire les modifications.

Concernant les colonnes elles serons toujours parfaitement identiques, chaque enregistrement correspond un transfert de donn�es g�n�r� par un arduino.
Dans le pire des cas la valeur sera nul avec un message d'erreur dans la colonne val6 et une indication visuelle pour alerter d'un message d'erreur.