Ouahou !
Je ne pensais pas trouver des choses aussi balèzes sur ce site !
100 000 mercis !
Pour ta fonction, je vais l'étudier avant de la mettre en prod, mais ça m'a l'air plus que bien, en effet.
La période la plus longue sera du 01/09 de l'année en cours au 31/08 de l'année suivante (année scolaire, donc), mais, car il y a toujours un mais, il y aura plusieurs accès concurentiels aux heures de pointes (une 100aine d'utilisateurs aux heures d'arrivée et de départ, c'est pour une application de pointage).
Pour la fonction overlaps, ça va m'éviter de charger ma base avec des trucs inutiles.
J'avais codé ça :
CREATE FUNCTION areExclusivePeriods(DATE, DATE, DATE, DATE)
RETURNS boolean AS'
DECLARE
debut1 ALIAS FOR 1ドル;
fin1 ALIAS FOR 2ドル;
debut2 ALIAS FOR 3ドル;
fin2 ALIAS FOR 4ドル;
retval boolean;
BEGIN
IF (((debut2 >= fin1) AND (fin2 > debut2)) or ((debut1 >= fin2) and (debut1 > fin1)))
then
retval := false;
else
retval := true;
end if;
return retval;
end;
' LANGUAGE 'plpgsql';
qui visiblement coûte autant de temps que la fonction overlaps...
En fait, je suis confronté à d'autres soucis depuis ce matin. Dans la table en question, il s'agit d'enregistrer un certain nombre d'informations par périodes.
Par défaut, chaque utilisateur a un enregistrement qui court du 01/09/200(n) au 31/08/200(n+1). Il peut sectionner cette période lors de l'ajout d'une nouvelle ligne, ça, j'ai réussi à le faire avec un trigger après insert. Mais je peux aussi avoir la solution inverse : l'aggrégat de périodes, fait after update.... Et ça, ben quand je le met en place, ça fout tout en l'air....
Je suis en train de me prendre la tête là dessus, et pour l'instant je n'ai pas de solution. Un petit exemple sera peut-être plus parlant....
Au début : période allant du 01/09 au 31/08 paramétré à 100 par défaut.
L'utilisateur indique un paramètre différent de celui par défaut, mettons 90 pour le mois de janvier.
Le after insert effectue dans l'ordre les opérations suivantes :
1) rétrécicessement de la période initiale du 01/09 au 31/12 avec pour paramètre 100,
2) insertion de la période allant du 01/02 au 31/08 avec pour paramètre 100,
3) renvoi des valeurs saisies par l'utilisateur (sa demande d'insertion) allant du 01/01 au 31/01 avec pour paramètre 90.
On peut répéter l'opération autant qu'on veut.
Par contre, si l'utilisateur veut modifier la période courant du 01/01 au 31/01 et en passer le paramètre à 100, il est inutile de conserver les 3 périodes.
Je voudrais donc trouver le moyen de mettre à jour la période
- avant
- après
- ou les 2 (ben oui, ce sont les 3 cas possibles) !
de façon à ne garder qu'une seule période : celle qui couvre l'intégralité des valeurs pour lesquelles le paramètre passe à 100... Et là, ça pêche....
Je cherche, je cherche, mais pour l'instant, je ne trouve pas....
Alors si l'un des mentors d'ici a une idée révolutionnaire, ou simplement un modèle qui répondrait plus à mes besoins, ce serait parfait !
En tout cas, je poursuis mes recherches en attendant.
Merci encore pour ton aide précieuse !
[^] # Re: peut-être une piste
Posté par Gyro Gearllose . En réponse au message SQL toujours : requête sur une non-table..... Évalué à 1.
Je ne pensais pas trouver des choses aussi balèzes sur ce site !
100 000 mercis !
Pour ta fonction, je vais l'étudier avant de la mettre en prod, mais ça m'a l'air plus que bien, en effet.
La période la plus longue sera du 01/09 de l'année en cours au 31/08 de l'année suivante (année scolaire, donc), mais, car il y a toujours un mais, il y aura plusieurs accès concurentiels aux heures de pointes (une 100aine d'utilisateurs aux heures d'arrivée et de départ, c'est pour une application de pointage).
Pour la fonction overlaps, ça va m'éviter de charger ma base avec des trucs inutiles.
J'avais codé ça :
CREATE FUNCTION areExclusivePeriods(DATE, DATE, DATE, DATE)
RETURNS boolean AS'
DECLARE
debut1 ALIAS FOR 1ドル;
fin1 ALIAS FOR 2ドル;
debut2 ALIAS FOR 3ドル;
fin2 ALIAS FOR 4ドル;
retval boolean;
BEGIN
IF (((debut2 >= fin1) AND (fin2 > debut2)) or ((debut1 >= fin2) and (debut1 > fin1)))
then
retval := false;
else
retval := true;
end if;
return retval;
end;
' LANGUAGE 'plpgsql';
qui visiblement coûte autant de temps que la fonction overlaps...
En fait, je suis confronté à d'autres soucis depuis ce matin. Dans la table en question, il s'agit d'enregistrer un certain nombre d'informations par périodes.
Par défaut, chaque utilisateur a un enregistrement qui court du 01/09/200(n) au 31/08/200(n+1). Il peut sectionner cette période lors de l'ajout d'une nouvelle ligne, ça, j'ai réussi à le faire avec un trigger après insert. Mais je peux aussi avoir la solution inverse : l'aggrégat de périodes, fait after update.... Et ça, ben quand je le met en place, ça fout tout en l'air....
Je suis en train de me prendre la tête là dessus, et pour l'instant je n'ai pas de solution. Un petit exemple sera peut-être plus parlant....
Au début : période allant du 01/09 au 31/08 paramétré à 100 par défaut.
L'utilisateur indique un paramètre différent de celui par défaut, mettons 90 pour le mois de janvier.
Le after insert effectue dans l'ordre les opérations suivantes :
1) rétrécicessement de la période initiale du 01/09 au 31/12 avec pour paramètre 100,
2) insertion de la période allant du 01/02 au 31/08 avec pour paramètre 100,
3) renvoi des valeurs saisies par l'utilisateur (sa demande d'insertion) allant du 01/01 au 31/01 avec pour paramètre 90.
On peut répéter l'opération autant qu'on veut.
Par contre, si l'utilisateur veut modifier la période courant du 01/01 au 31/01 et en passer le paramètre à 100, il est inutile de conserver les 3 périodes.
Je voudrais donc trouver le moyen de mettre à jour la période
- avant
- après
- ou les 2 (ben oui, ce sont les 3 cas possibles) !
de façon à ne garder qu'une seule période : celle qui couvre l'intégralité des valeurs pour lesquelles le paramètre passe à 100... Et là, ça pêche....
Je cherche, je cherche, mais pour l'instant, je ne trouve pas....
Alors si l'un des mentors d'ici a une idée révolutionnaire, ou simplement un modèle qui répondrait plus à mes besoins, ce serait parfait !
En tout cas, je poursuis mes recherches en attendant.
Merci encore pour ton aide précieuse !