dans une table d'alerte,
j'ai une date à laquelle a été crée l'alarte,
le libélé de l'alerte
et le nombe de jours apres lequel l'alert doit se déclancher...
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
ManuPavy
Etienne SOBOLE wrote:
salut.
dans une table d'alerte, j'ai une date à laquelle a été crée l'alarte, le libélé de l'alerte et le nombe de jours apres lequel l'alert doit se déclancher...
comment selectionner les alert active. un truc du genre SELECT idalert, desription FROM alert WHERE (alert_date + nbjour) > 'now';
c'est possible de faire ca en SQL ??? merci Etienne
Bonjour, En Mysql, il existe adddate() et dateadd() en sqlserver je crois. sinon, convertir la date en jour pour l'ajouter au nombre de jour pour reconvertir le tout en date. Dans tous les cas, un article existe : http://sql.developpez.com/gestiontemps/
Manu
Etienne SOBOLE wrote:
salut.
dans une table d'alerte,
j'ai une date à laquelle a été crée l'alarte,
le libélé de l'alerte
et le nombe de jours apres lequel l'alert doit se déclancher...
comment selectionner les alert active.
un truc du genre
SELECT idalert, desription FROM alert WHERE (alert_date + nbjour) > 'now';
c'est possible de faire ca en SQL ???
merci
Etienne
Bonjour,
En Mysql, il existe adddate() et dateadd() en sqlserver je crois.
sinon, convertir la date en jour pour l'ajouter au nombre de jour pour
reconvertir le tout en date.
Dans tous les cas, un article existe :
http://sql.developpez.com/gestiontemps/
dans une table d'alerte, j'ai une date à laquelle a été crée l'alarte, le libélé de l'alerte et le nombe de jours apres lequel l'alert doit se déclancher...
comment selectionner les alert active. un truc du genre SELECT idalert, desription FROM alert WHERE (alert_date + nbjour) > 'now';
c'est possible de faire ca en SQL ??? merci Etienne
Bonjour, En Mysql, il existe adddate() et dateadd() en sqlserver je crois. sinon, convertir la date en jour pour l'ajouter au nombre de jour pour reconvertir le tout en date. Dans tous les cas, un article existe : http://sql.developpez.com/gestiontemps/
Manu
Etienne SOBOLE
Bonjour, En Mysql, il existe adddate() et dateadd() en sqlserver je crois.
Je suis sous postgreSQL
sinon, convertir la date en jour pour l'ajouter au nombre de jour pour reconvertir le tout en date. Dans tous les cas, un article existe : http://sql.developpez.com/gestiontemps/
Mais c'est un truc de ouf ce machin...
Non moi je suis pas du genre a me prendre la tête a ce point la ;) Etienne...
Bonjour,
En Mysql, il existe adddate() et dateadd() en sqlserver je crois.
Je suis sous postgreSQL
sinon, convertir la date en jour pour l'ajouter au nombre de jour pour
reconvertir le tout en date.
Dans tous les cas, un article existe :
http://sql.developpez.com/gestiontemps/
Mais c'est un truc de ouf ce machin...
Non moi je suis pas du genre a me prendre la tête a ce point la ;)
Etienne...
Bonjour, En Mysql, il existe adddate() et dateadd() en sqlserver je crois.
Je suis sous postgreSQL
sinon, convertir la date en jour pour l'ajouter au nombre de jour pour reconvertir le tout en date. Dans tous les cas, un article existe : http://sql.developpez.com/gestiontemps/
Mais c'est un truc de ouf ce machin...
Non moi je suis pas du genre a me prendre la tête a ce point la ;) Etienne...
Ca y est j'ai trouvé un truc qui marche sous postgreSQL SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours || ' days') > 'now';
quelqu'un peu me dire si ca marche aussi sur les autres SGBD ? merci.
Ca y est j'ai trouvé un truc qui marche sous postgreSQL
SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours
|| ' days') > 'now';
quelqu'un peu me dire si ca marche aussi sur les autres SGBD ?
merci.
Ca y est j'ai trouvé un truc qui marche sous postgreSQL SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours || ' days') > 'now';
quelqu'un peu me dire si ca marche aussi sur les autres SGBD ? merci.
Ca y est j'ai trouvé un truc qui marche sous postgreSQL SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours || ' days') > 'now';
quelqu'un peu me dire si ca marche aussi sur les autres SGBD ? merci.
Etienne
Après test, celà n'a pas l'air de marcher sous MySQL (qui à priori remplace l'opérateur d'addition par adddate(), tout simplement)
Ca y est j'ai trouvé un truc qui marche sous postgreSQL
SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours
|| ' days') > 'now';
quelqu'un peu me dire si ca marche aussi sur les autres SGBD ?
merci.
Etienne
Après test, celà n'a pas l'air de marcher sous MySQL (qui à priori
remplace l'opérateur d'addition par adddate(), tout simplement)
Ca y est j'ai trouvé un truc qui marche sous postgreSQL SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours || ' days') > 'now';
quelqu'un peu me dire si ca marche aussi sur les autres SGBD ? merci.
Etienne
Après test, celà n'a pas l'air de marcher sous MySQL (qui à priori remplace l'opérateur d'addition par adddate(), tout simplement)
Manu
Jacques Caron
Salut,
On Fri, 11 Mar 2005 10:27:21 +0100, Etienne SOBOLE wrote:
Ca y est j'ai trouvé un truc qui marche sous postgreSQL SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours || ' days') > 'now';
Oui, ça marche, mais j'espère pour toi que tu ne comptes pas avoir beaucoup d'alertes: il n'est pas possible d'utiliser d'index pour ce type de requête.
Il serait probablement plus pertinent de stocker dans la table la date à laquelle l'alerte doit de déclencher et faire la comparaison dessus directement.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Fri, 11 Mar 2005 10:27:21 +0100, Etienne SOBOLE <etienne-nospam@tlk.fr>
wrote:
Ca y est j'ai trouvé un truc qui marche sous postgreSQL
SELECT idalert, description FROM alert WHERE alerte_date + interval
(nbjours || ' days') > 'now';
Oui, ça marche, mais j'espère pour toi que tu ne comptes pas avoir
beaucoup d'alertes: il n'est pas possible d'utiliser d'index pour ce type
de requête.
Il serait probablement plus pertinent de stocker dans la table la date à
laquelle l'alerte doit de déclencher et faire la comparaison dessus
directement.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Fri, 11 Mar 2005 10:27:21 +0100, Etienne SOBOLE wrote:
Ca y est j'ai trouvé un truc qui marche sous postgreSQL SELECT idalert, description FROM alert WHERE alerte_date + interval (nbjours || ' days') > 'now';
Oui, ça marche, mais j'espère pour toi que tu ne comptes pas avoir beaucoup d'alertes: il n'est pas possible d'utiliser d'index pour ce type de requête.
Il serait probablement plus pertinent de stocker dans la table la date à laquelle l'alerte doit de déclencher et faire la comparaison dessus directement.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Etienne SOBOLE
Il serait probablement plus pertinent de stocker dans la table la date à laquelle l'alerte doit de déclencher et faire la comparaison dessus directement.
Hum ben non ca c'est guere possible. Chaque utilisateur peux definir un nombre de jours a partir duquel il va voir l'alerte... donc tu vois avec 10 utilisateurs, il faudrait 10 colonnes par alertes... De toute façon il n'y a pas de limite en ce qui concerne le nombre d'utilisateur, ce qui coupe court a la discussion ;)
pas glop... Etienne
Il serait probablement plus pertinent de stocker dans la table la date à
laquelle l'alerte doit de déclencher et faire la comparaison dessus
directement.
Hum ben non ca c'est guere possible.
Chaque utilisateur peux definir un nombre de jours a partir duquel il va
voir l'alerte...
donc tu vois avec 10 utilisateurs, il faudrait 10 colonnes par alertes...
De toute façon il n'y a pas de limite en ce qui concerne le nombre
d'utilisateur, ce qui coupe court a la discussion ;)
Il serait probablement plus pertinent de stocker dans la table la date à laquelle l'alerte doit de déclencher et faire la comparaison dessus directement.
Hum ben non ca c'est guere possible. Chaque utilisateur peux definir un nombre de jours a partir duquel il va voir l'alerte... donc tu vois avec 10 utilisateurs, il faudrait 10 colonnes par alertes... De toute façon il n'y a pas de limite en ce qui concerne le nombre d'utilisateur, ce qui coupe court a la discussion ;)
pas glop... Etienne
Jacques Caron
On Fri, 11 Mar 2005 11:28:19 +0100, Etienne SOBOLE wrote:
Chaque utilisateur peux definir un nombre de jours a partir duquel il va voir l'alerte... donc tu vois avec 10 utilisateurs, il faudrait 10 colonnes par alertes... De toute façon il n'y a pas de limite en ce qui concerne le nombre d'utilisateur, ce qui coupe court a la discussion ;)
Ca ne correspond pas trop au modèle que tu décrivais au début, si? Mais si le délai d'alerte est spécifique à chaque utilisateur, c'est pas très grave, un alerte.date_alerte > now()-(utilisateur.delai_alerte||'days')::interval pourra utiliser un index, donc tout va bien.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Fri, 11 Mar 2005 11:28:19 +0100, Etienne SOBOLE <etienne-nospam@tlk.fr>
wrote:
Chaque utilisateur peux definir un nombre de jours a partir duquel il va
voir l'alerte...
donc tu vois avec 10 utilisateurs, il faudrait 10 colonnes par alertes...
De toute façon il n'y a pas de limite en ce qui concerne le nombre
d'utilisateur, ce qui coupe court a la discussion ;)
Ca ne correspond pas trop au modèle que tu décrivais au début, si? Mais si
le délai d'alerte est spécifique à chaque utilisateur, c'est pas très
grave, un alerte.date_alerte >
now()-(utilisateur.delai_alerte||'days')::interval pourra utiliser un
index, donc tout va bien.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Fri, 11 Mar 2005 11:28:19 +0100, Etienne SOBOLE wrote:
Chaque utilisateur peux definir un nombre de jours a partir duquel il va voir l'alerte... donc tu vois avec 10 utilisateurs, il faudrait 10 colonnes par alertes... De toute façon il n'y a pas de limite en ce qui concerne le nombre d'utilisateur, ce qui coupe court a la discussion ;)
Ca ne correspond pas trop au modèle que tu décrivais au début, si? Mais si le délai d'alerte est spécifique à chaque utilisateur, c'est pas très grave, un alerte.date_alerte > now()-(utilisateur.delai_alerte||'days')::interval pourra utiliser un index, donc tout va bien.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Etienne SOBOLE
Ca ne correspond pas trop au modèle que tu décrivais au début, si? Mais si le délai d'alerte est spécifique à chaque utilisateur, c'est pas très grave, un alerte.date_alerte > now()-(utilisateur.delai_alerte||'days')::interval pourra utiliser un index, donc tout va bien.
exact! ;)
merci Etienne
Ca ne correspond pas trop au modèle que tu décrivais au début, si? Mais si
le délai d'alerte est spécifique à chaque utilisateur, c'est pas très
grave, un alerte.date_alerte >
now()-(utilisateur.delai_alerte||'days')::interval pourra utiliser un
index, donc tout va bien.
Ca ne correspond pas trop au modèle que tu décrivais au début, si? Mais si le délai d'alerte est spécifique à chaque utilisateur, c'est pas très grave, un alerte.date_alerte > now()-(utilisateur.delai_alerte||'days')::interval pourra utiliser un index, donc tout va bien.
