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.