dans laquelle sont enregistrés des évenements éventuels et
indépendants.
Existe t'il une requête qui me permette de récupérer en une fois les
derniers états des évenements ?
pour l'instant je fait :
SELECT event1 FROM table WHERE event1<>'' ORDER BY DATE DESC LIMIT 1
et ce pour chaque évenement mais je trouve que c'est un peu lourd
surtout si le nombre d'évenement augmente.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry Thomas
Mercredi 23 avril 2008 à 11:57 GMT, Gilles RONSIN a écrit :
bonjour,
Bonsoir,
j'utilise une table journal de type
index ----- date event1 event2 event3 autre
dans laquelle sont enregistrés des évenements éventuels et indépendants.
Existe t'il une requête qui me permette de récupérer en une fois les derniers états des évenements ?
Ne serait-il pas possible de modifier la structure de cette table, pour la normaliser ? Les événements devraient être dans une table fille, un seul par enregistrement. -- Th. Thomas.
Mercredi 23 avril 2008 à 11:57 GMT, Gilles RONSIN a écrit :
bonjour,
Bonsoir,
j'utilise une table journal de type
index
-----
date
event1
event2
event3
autre
dans laquelle sont enregistrés des évenements éventuels et
indépendants.
Existe t'il une requête qui me permette de récupérer en une fois les
derniers états des évenements ?
Ne serait-il pas possible de modifier la structure de cette table, pour
la normaliser ? Les événements devraient être dans une table fille, un
seul par enregistrement.
--
Th. Thomas.
Mercredi 23 avril 2008 à 11:57 GMT, Gilles RONSIN a écrit :
bonjour,
Bonsoir,
j'utilise une table journal de type
index ----- date event1 event2 event3 autre
dans laquelle sont enregistrés des évenements éventuels et indépendants.
Existe t'il une requête qui me permette de récupérer en une fois les derniers états des évenements ?
Ne serait-il pas possible de modifier la structure de cette table, pour la normaliser ? Les événements devraient être dans une table fille, un seul par enregistrement. -- Th. Thomas.
Gilles RONSIN
Thierry Thomas , le mer. 23 avr. 2008 20:58:41, écrivait ceci:
Existe t'il une requête qui me permette de récupérer en une fois les derniers états des évenements ?
Ne serait-il pas possible de modifier la structure de cette table, pour la normaliser ? Les événements devraient être dans une table fille, un seul par enregistrement.
Salut, L'évènement est simple : absent c'est vide, passage de OFF à ON c'est '1', passage de ON à OFF c'est '0' pour chaque évenement je veux retrouver la date où il a changé d'état. Pas besoin d'une table fille; où alors je n'ai pas compris ce à quoi tu penses.
Je pensais apprendre une requête de folie (je débute en mysql) car je suis sûr de ne pas soupsonner 1/4 des possibilités des requêtes.
Pour mon problème, j'ai résolu en utilisant un champ d'état dans une autre table, qui répertorie le dernier état connu !
Merci en tout cas de ta réponse.
Thierry Thomas <tthomas@mail.dotcom.fr>, le mer. 23 avr. 2008
20:58:41, écrivait ceci:
Existe t'il une requête qui me permette de récupérer en une fois
les derniers états des évenements ?
Ne serait-il pas possible de modifier la structure de cette table,
pour la normaliser ? Les événements devraient être dans une table
fille, un seul par enregistrement.
Salut,
L'évènement est simple : absent c'est vide, passage de OFF à ON c'est
'1', passage de ON à OFF c'est '0'
pour chaque évenement je veux retrouver la date où il a changé d'état.
Pas besoin d'une table fille; où alors je n'ai pas compris ce à quoi tu
penses.
Je pensais apprendre une requête de folie (je débute en mysql) car je
suis sûr de ne pas soupsonner 1/4 des possibilités des requêtes.
Pour mon problème, j'ai résolu en utilisant un champ d'état dans une
autre table, qui répertorie le dernier état connu !
Thierry Thomas , le mer. 23 avr. 2008 20:58:41, écrivait ceci:
Existe t'il une requête qui me permette de récupérer en une fois les derniers états des évenements ?
Ne serait-il pas possible de modifier la structure de cette table, pour la normaliser ? Les événements devraient être dans une table fille, un seul par enregistrement.
Salut, L'évènement est simple : absent c'est vide, passage de OFF à ON c'est '1', passage de ON à OFF c'est '0' pour chaque évenement je veux retrouver la date où il a changé d'état. Pas besoin d'une table fille; où alors je n'ai pas compris ce à quoi tu penses.
Je pensais apprendre une requête de folie (je débute en mysql) car je suis sûr de ne pas soupsonner 1/4 des possibilités des requêtes.
Pour mon problème, j'ai résolu en utilisant un champ d'état dans une autre table, qui répertorie le dernier état connu !
Merci en tout cas de ta réponse.
Jerome PAULIN
Gilles RONSIN a écrit :
Pour mon problème, j'ai résolu en utilisant un champ d'état dans une autre table, qui répertorie le dernier état connu !
Combine cette table avec un trigger (pour les MAJ automatiques), et tu auras ce dont tu as besoin : une table d'état et une table d'historique ...
gg
Gilles RONSIN a écrit :
Pour mon problème, j'ai résolu en utilisant un champ d'état dans une
autre table, qui répertorie le dernier état connu !
Combine cette table avec un trigger (pour les MAJ automatiques), et tu
auras ce dont tu as besoin : une table d'état et une table d'historique ...
Combine cette table avec un trigger (pour les MAJ automatiques), et tu auras ce dont tu as besoin : une table d'état et une table d'historique ...
Désolé, je ne comprend pas. :-/ Actuellement j'ai effectivement une table d'état et une table historique. Qu'appelles-tu un trigger ? Qu'appelles-tu mise à jour automatique ?
Combine cette table avec un trigger (pour les MAJ automatiques),
et tu auras ce dont tu as besoin : une table d'état et une table
d'historique ...
Désolé, je ne comprend pas. :-/
Actuellement j'ai effectivement une table d'état et une table
historique.
Qu'appelles-tu un trigger ? Qu'appelles-tu mise à jour automatique ?
Combine cette table avec un trigger (pour les MAJ automatiques), et tu auras ce dont tu as besoin : une table d'état et une table d'historique ...
Désolé, je ne comprend pas. :-/ Actuellement j'ai effectivement une table d'état et une table historique. Qu'appelles-tu un trigger ? Qu'appelles-tu mise à jour automatique ?
Jerome PAULIN
Gilles RONSIN a écrit :
Désolé, je ne comprend pas. :-/ Actuellement j'ai effectivement une table d'état et une table historique. Qu'appelles-tu un trigger ? Qu'appelles-tu mise à jour automatique ?
Comment mets tu ta table d'état à jour ? --> certainement via ton application.
Un trigger est un système qui permet d'executer une action sur une table lorsqu'il se produit un évènement sur une (autre) table.
exemple : lorsque l'on insère un enregistrement dans la table historique, il est possible de mettre à jour automatiquement la table d'état, au niveau de la base de données. Cela te permets de ne pas avoir à gérer la mise à jour de la table d'état depuis ton application (il suffit d'insérer un enregistrement dans la table historique). C'est très pratique et simple a mettre en oeuvre (à partir de MySQL5).
Exemple : j'ai une table projects (qui contient une liste de projets) et une table teams (qui contient les membres de l'equipe projet). J'ai besoin d'ajouter systématiquement un membre (appelon le le superviseur) dans les projets nouveaux. J'ai donc créé le trigger suivant :
CREATE TRIGGER `projects_after_ins_tr` AFTER INSERT ON `projects` FOR EACH ROW BEGIN insert into teams(project,member,published,authorized) values(new.id,7,1,0); END;
ce qui signifie : apres une insertion dans la table projects, insère un enregistrement dans la table teams, puis je donne la valeur des champs a inserer. new.id représente le id qui vient d'etre généré au niveau de la table projects
Est ce que ce petit exemple te permets de mieux comprendre le principe des triggers ?
gg
Gilles RONSIN a écrit :
Désolé, je ne comprend pas. :-/
Actuellement j'ai effectivement une table d'état et une table
historique.
Qu'appelles-tu un trigger ? Qu'appelles-tu mise à jour automatique ?
Comment mets tu ta table d'état à jour ? --> certainement via ton
application.
Un trigger est un système qui permet d'executer une action sur une table
lorsqu'il se produit un évènement sur une (autre) table.
exemple : lorsque l'on insère un enregistrement dans la table
historique, il est possible de mettre à jour automatiquement la table
d'état, au niveau de la base de données. Cela te permets de ne pas avoir
à gérer la mise à jour de la table d'état depuis ton application (il
suffit d'insérer un enregistrement dans la table historique). C'est très
pratique et simple a mettre en oeuvre (à partir de MySQL5).
Exemple :
j'ai une table projects (qui contient une liste de projets) et une table
teams (qui contient les membres de l'equipe projet). J'ai besoin
d'ajouter systématiquement un membre (appelon le le superviseur) dans
les projets nouveaux. J'ai donc créé le trigger suivant :
CREATE TRIGGER `projects_after_ins_tr` AFTER INSERT ON `projects`
FOR EACH ROW
BEGIN
insert into teams(project,member,published,authorized)
values(new.id,7,1,0);
END;
ce qui signifie : apres une insertion dans la table projects, insère un
enregistrement dans la table teams, puis je donne la valeur des champs a
inserer. new.id représente le id qui vient d'etre généré au niveau de la
table projects
Est ce que ce petit exemple te permets de mieux comprendre le principe
des triggers ?
Désolé, je ne comprend pas. :-/ Actuellement j'ai effectivement une table d'état et une table historique. Qu'appelles-tu un trigger ? Qu'appelles-tu mise à jour automatique ?
Comment mets tu ta table d'état à jour ? --> certainement via ton application.
Un trigger est un système qui permet d'executer une action sur une table lorsqu'il se produit un évènement sur une (autre) table.
exemple : lorsque l'on insère un enregistrement dans la table historique, il est possible de mettre à jour automatiquement la table d'état, au niveau de la base de données. Cela te permets de ne pas avoir à gérer la mise à jour de la table d'état depuis ton application (il suffit d'insérer un enregistrement dans la table historique). C'est très pratique et simple a mettre en oeuvre (à partir de MySQL5).
Exemple : j'ai une table projects (qui contient une liste de projets) et une table teams (qui contient les membres de l'equipe projet). J'ai besoin d'ajouter systématiquement un membre (appelon le le superviseur) dans les projets nouveaux. J'ai donc créé le trigger suivant :
CREATE TRIGGER `projects_after_ins_tr` AFTER INSERT ON `projects` FOR EACH ROW BEGIN insert into teams(project,member,published,authorized) values(new.id,7,1,0); END;
ce qui signifie : apres une insertion dans la table projects, insère un enregistrement dans la table teams, puis je donne la valeur des champs a inserer. new.id représente le id qui vient d'etre généré au niveau de la table projects
Est ce que ce petit exemple te permets de mieux comprendre le principe des triggers ?
Comment mets tu ta table d'état à jour ? --> certainement via ton application.
En fait, j'ai un serveur de communication qui reçoit des données de boîtiers dans la nature. Ce serveur de com, renseigne les tables en fonction des paramètres transmis. J'écris donc la communication dans la table historique, et maintenant je maintiens un flag de status en fonction des évenements dans la table de propriété.
Un trigger est un système qui permet d'executer une action sur une table lorsqu'il se produit un évènement sur une (autre) table.
exemple : lorsque l'on insère un enregistrement dans la table historique, il est possible de mettre à jour automatiquement la table d'état, au niveau de la base de données. Cela te permets de ne pas avoir à gérer la mise à jour de la table d'état depuis ton application (il suffit d'insérer un enregistrement dans la table historique). C'est très pratique et simple a mettre en oeuvre (à partir de MySQL5).
En effet c'est très interessant. Par contre, je ne suis pas sûr que ce soit la meilleure solution dans mon cas (j'ai des vérifications voire des données à retourner).
Exemple : <snip> CREATE TRIGGER `projects_after_ins_tr` AFTER INSERT ON `projects` FOR EACH ROW BEGIN insert into teams(project,member,published,authorized) values(new.id,7,1,0); END; <snip> Est ce que ce petit exemple te permets de mieux comprendre le principe des triggers ?
Toutafé. Je pense que je n'ai pas fini d'en apprendre sur les requêtes. C'est d'ailleurs la principale raison de mes post ici. Même si j'ai une solution, il y a souvent mieux à faire.
En tout cas merci pour ton cours. Très instructif.
Comment mets tu ta table d'état à jour ? --> certainement via ton
application.
En fait, j'ai un serveur de communication qui reçoit des données de
boîtiers dans la nature. Ce serveur de com, renseigne les tables en
fonction des paramètres transmis. J'écris donc la communication dans la
table historique, et maintenant je maintiens un flag de status en
fonction des évenements dans la table de propriété.
Un trigger est un système qui permet d'executer une action sur une
table lorsqu'il se produit un évènement sur une (autre) table.
exemple : lorsque l'on insère un enregistrement dans la table
historique, il est possible de mettre à jour automatiquement la
table d'état, au niveau de la base de données. Cela te permets de
ne pas avoir à gérer la mise à jour de la table d'état depuis ton
application (il suffit d'insérer un enregistrement dans la table
historique). C'est très pratique et simple a mettre en oeuvre (à
partir de MySQL5).
En effet c'est très interessant. Par contre, je ne suis pas sûr que ce
soit la meilleure solution dans mon cas (j'ai des vérifications voire
des données à retourner).
Exemple :
<snip>
CREATE TRIGGER `projects_after_ins_tr` AFTER INSERT ON `projects`
FOR EACH ROW
BEGIN
insert into teams(project,member,published,authorized)
values(new.id,7,1,0);
END;
<snip>
Est ce que ce petit exemple te permets de mieux comprendre le
principe des triggers ?
Toutafé. Je pense que je n'ai pas fini d'en apprendre sur les requêtes.
C'est d'ailleurs la principale raison de mes post ici. Même si j'ai une
solution, il y a souvent mieux à faire.
En tout cas merci pour ton cours. Très instructif.
Comment mets tu ta table d'état à jour ? --> certainement via ton application.
En fait, j'ai un serveur de communication qui reçoit des données de boîtiers dans la nature. Ce serveur de com, renseigne les tables en fonction des paramètres transmis. J'écris donc la communication dans la table historique, et maintenant je maintiens un flag de status en fonction des évenements dans la table de propriété.
Un trigger est un système qui permet d'executer une action sur une table lorsqu'il se produit un évènement sur une (autre) table.
exemple : lorsque l'on insère un enregistrement dans la table historique, il est possible de mettre à jour automatiquement la table d'état, au niveau de la base de données. Cela te permets de ne pas avoir à gérer la mise à jour de la table d'état depuis ton application (il suffit d'insérer un enregistrement dans la table historique). C'est très pratique et simple a mettre en oeuvre (à partir de MySQL5).
En effet c'est très interessant. Par contre, je ne suis pas sûr que ce soit la meilleure solution dans mon cas (j'ai des vérifications voire des données à retourner).
Exemple : <snip> CREATE TRIGGER `projects_after_ins_tr` AFTER INSERT ON `projects` FOR EACH ROW BEGIN insert into teams(project,member,published,authorized) values(new.id,7,1,0); END; <snip> Est ce que ce petit exemple te permets de mieux comprendre le principe des triggers ?
Toutafé. Je pense que je n'ai pas fini d'en apprendre sur les requêtes. C'est d'ailleurs la principale raison de mes post ici. Même si j'ai une solution, il y a souvent mieux à faire.
En tout cas merci pour ton cours. Très instructif.
