[MSSQLSERVER2008R2]Requete SQL Avec Datediff et gestion des jour Fériés

Version imprimable

27/10/2011, 12h33
HelpmeMM

[MSSQLSERVER2008R2]Requete SQL Avec Datediff et gestion des jour Fériés

Bonjour,

Je fait appel a vous car j'ai une interrogation sur un datediff un peu spécial dans une REQUETE SQL

En effet je souhaite faire une différence entre 2 date pour récupéré le nombre de jours moins les jours fériés

Par exemple si je prend
le Vendredi 21 et le lundi 24 je souhaite que l'on me retourne 1 et non pas 3 de même si je prend le Vendredi 21 et le lundi 31 je souhaite que l'on me retourne 6 et non pas 10 cela doit aussi marché avec les journée comme le 14 juillet ou le 15 aout.

Si vous avez des solutions sur un algo qui fonctionnerait je suis preneur je continue a chercher de mon coté pour le moment.

merci à la communauté .
27/10/2011, 14h41
Invité

Type de problème régulièrement posé ici, notamment hier...
Créez une table de date avec un booléen pour férié ou pas et par requête, tu pourras avoir la somme des jours fériés ou pas.
27/10/2011, 14h57
SQLpro

Inspirez vous de l'article que j'ai écrit à cet effet : http://sqlpro.developpez.com/cours/gestiontemps/

A +
27/10/2011, 15h20
Invité

Citation:

Envoyé par SQLpro

Inspirez vous de l'article que j'ai écrit à cet effet : http://sqlpro.developpez.com/cours/gestiontemps/

J'avais jamais vu cette article très complet. Merci bien, SQLPro.
27/10/2011, 16h55
HelpmeMM

Citation:

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Type de problème régulièrement posé ici, notamment hier...
Créez une table de date avec un booléen pour férié ou pas et par requête, tu pourras avoir la somme des jours fériés ou pas.

je vais faire comme si j'avais pas vu la première ligne qui n'apporte évidemment aucun élément de réponse en plus d’être Irritante

Bref mon problème n'est pas de savoir quand un jour est férié car j'ai déjà une table calendrier construite sur le modèle d'SQlPro qui me ramène par jour le mois, la semaine, l'année, et si le jour est férié oui ou non depuis un bon moment

Mon problème était surtout de savoir comment l'implémenter dans ma requête, j'ai sans doute du mal m'exprimer.

En y réfléchissant de plus près le mieux est d'avoir une fonction Sql auquel je fait appel et qui va me ramener un entier X étant mon nombre de jour férié dans mon intervalle de temps

Merci néanmoins pour les conseils avisés.

Au final la solution :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Create Function [dbo].[JourFerie] (@Date Datetime) returns Bit
AS 
Begin
 
Declare @Jour as integer
Declare @Mois as integer
Declare @Annee As Integer
Declare @Resultat as Bit
Declare @NbOr as integer
Declare @Epacte as integer
Declare @DatePLune as datetime
Declare @LundiPaques as datetime
Declare @JeudiAscension as datetime
Declare @LundiPentecote as datetime
 
 
set @Jour = Day(@date)
set @Mois = Month(@date)
set @Annee = Year(@date)
set @NbOr = (@Annee % 19) + 1
set @Epacte = (11 * @NbOr - (3 + round((2 + Round(@Annee / 100,0)) * 3 / 7,0))) % 30
set @DatePLune = dateadd(day,((@Epacte + 6) % 30) * -1, cast('19/04/' + cast(@Annee as varchar(4)) as datetime))
 
set @DatePLune = dateadd(day, case when @Epacte = 24 
								or (@Epacte = 25 and @Annee >= 1900 and @Annee < 2000 ) 
							then - 1
				else 0
			end, @DatePLune)
 
set @LundiPaques = dateAdd(day, 8 - datepart(weekday,@DatePLune), @DatePLune)
 
set @JeudiAscension = dateadd(day,38,@LundiPaques)
 
set @LundiPentecote = dateadd(day,11,@JeudiAscension)
 
set @Resultat = 
Case 
	when left(convert(varchar(10),@Date,103),5) 
		in ('01/01','01/05','08/05','14/07','15/08','01/11','11/11','25/12')
		or @Date in (@LundiPaques,@JeudiAscension,@LundiPentecote) then 1
	else 0
end 
 
return @Resultat
 
end 
GO

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE Function [dbo].[NBJourFerie] (@DateDebut Datetime,@DateFin Datetime) returns Integer
 
Begin
Declare @NbJourFerie as Integer
 
Set @NbJourFerie =(
Select Sum(NbJourFerie)from(
Select Case when Dbo.F_ISO_WEEKDAY(Jour)=6 then 1
			when Dbo.F_ISO_WEEKDAY(Jour)=7 then 1 
			else  Dbo.JourFerie(jour)end as NbJourFerie,jour  
			from TBA_Calendrier
			where Jour Between  @DateDebut and @DateFin) As T
)
return @NbJourFerie
 
end

POur la somme du nb de jour férié j'utilise une fonction F_Iso_weekday qui n'est pas présenté ici car facile a trouver sur le net. Cette fonction a le mérite de calculé a la volé mon nb de jour férié et évite ainsi toute modification dans la table Calendrier.

28/10/2011, 11h18
SQLpro
Je voit pas l'intérêt d'une UDF à moins de vouloir pourrir sciemment les perf.

Si vous avez une colonne FERIE de type BIT dans votre table de date, il suffit de faire :
Code:

1 2 3 SELECT SUM(FERIE) FROM T_DATES WHERE JOUR BETWEEN ???debut??? AND ???FIN???
Avec un index sur JOUR + FERIE, c'est instantané.

A +
28/10/2011, 14h20
HelpmeMM

il y a deux raisons à ce choix :

1-Tout simplement car je suis sur une table qui contient moins de 100 000 enregistrements et que les perfs ne sont clairement pas un problème pour moi
et ne sont pas pres de le devenir

2- car cela est clairement plus simple a gérer puisque cela m'évite de rajouter des jointures. La finalité n'étant pas de récupérer le nombre de jours férié mais de calculer une durée en minutes entre deux date suivant d'autres paramètres. D'autant que ma table calendrier est dans une autre bases de donnée et que je ne souhaite pas la dupliqué dans cette base.

peut être qu'effectivement sa pourrie les perfs mais ce n'est pas ce que dit le rendu de mon état qui est instantané le nombre de donnée traité avec les différents filtres dépassant rarement le millier.
30/10/2011, 06h32
elsuket

Citation:

1-Tout simplement car je suis sur une table qui contient moins de 100 000 enregistrements et que les perfs ne sont clairement pas un problème pour moi et ne sont pas pres de le devenir

C'est typique du comportement "bah ça se voit pas, on s'en fout" ...
Pourquoi faire performant quand on peut faire contre-performant ?
Décidément la quantité de travail des consultants (qui au final passent 50% de leur temps à faire le travail des autres correctement) n'est pas près de disparaître avec de tels raisonnements.

Citation:

car cela est clairement plus simple a gérer puisque cela m'évite de rajouter des jointures

Effectivement, quoi de moins naturel dans un SGBDR que la jointure ...

Citation:

D'autant que ma table calendrier est dans une autre bases de donnée et que je ne souhaite pas la dupliqué dans cette base.

Je ne vois vraiment pas le problème que cela pose ...

Citation:

peut être qu'effectivement sa pourrie les perfs mais ce n'est pas ce que dit le rendu de mon état qui est instantané le nombre de donnée traité avec les différents filtres dépassant rarement le millier.

Ceci parce que la quantité de données que vous lisez est inférieure à la taille de la RAM disponible sur le serveur et allouée à SQL Server.
Quand vous la dépasserez, ce sera une autre histoire.

Enfin, comme disent Laspalès et Chevalier : "c'est vous qui voyez; y'en a qu'ont essayé, ils ont eu des problèmes" ;)

@++ ;)
14/11/2011, 18h02
HelpmeMM

Citation:

Envoyé par elsuket

C'est typique du comportement "bah ça se voit pas, on s'en fout" ...
Pourquoi faire performant quand on peut faire contre-performant ?
Décidément la quantité de travail des consultants (qui au final passent 50% de leur temps à faire le travail des autres correctement) n'est pas près de disparaître avec de tels raisonnements.

Effectivement, quoi de moins naturel dans un SGBDR que la jointure ...

Je ne vois vraiment pas le problème que cela pose ...

Ceci parce que la quantité de données que vous lisez est inférieure à la taille de la RAM disponible sur le serveur et allouée à SQL Server.
Quand vous la dépasserez, ce sera une autre histoire.

Enfin, comme disent Laspalès et Chevalier : "c'est vous qui voyez; y'en a qu'ont essayé, ils ont eu des problèmes" ;)

@++ ;)

Et ce genre de réponse est typique des personnes extérieures au projet et qui ne sont pas confrontées directement aux problèmes, mais qui se permettent de critiquer parce qu'elle pense que tout est toujours simple et qu'il n'y a toujours qu'une façon de faire ... la leur.

Mais bon je me doutais qu'en me justifiant j'aurais ce genre de remarque douteuse.

Quand on vous demande un travail pour hier on a pas forcément le temps de faire le projet comme on l'aurait souhaité mais bon c'est sans doute pas un problème de consultant...:mrgreen::mrgreen::mrgreen:
17/11/2011, 15h45
Jinroh77

C'est justement le rôle du consultant, qui n'est pas développeur, d'expliquer à son client qu'il lui faut 15min de plus pour réaliser les jointures supplémentaires plutôt que d'utiliser une UDF.
Le consultant est consulté pour ses conseils et son expertise. A moins de n’être que le titre donné par ces SSII type "boite à viande" lorsqu'ils présentent leur profil.
18/11/2011, 21h00
iberserk

Citation:

C'est justement le rôle du consultant, qui n'est pas développeur, d'expliquer à son client qu'il lui faut 15min de plus pour réaliser les jointures supplémentaires plutôt que d'utiliser une UDF.

Difficile d'expliquer qui plus est qu'il vous faille moins de temps pour faire une UDF qu'une jointure...
Vous avez des cours sur les jointures sur le site d'SQLPRO :ccool:

Citation:

D'autant que ma table calendrier est dans une autre bases de donnée et que je ne souhaite pas la dupliqué dans cette base.

Même si je n'ai qu'un misérable regard extérieur sur votre problème, je ne vois pas en quoi il est compliqué de créer votre table calendrier sur ladite base?

Citation:

Et ce genre de réponse est typique des personnes extérieures au projet et qui ne sont pas confrontées directement aux problèmes, mais qui se permettent de critiquer parce qu'elle pense que tout est toujours simple et qu'il n'y a toujours qu'une façon de faire ... la leur.

Comprenez que nous sommes confronté quotidiennement a des personnes qui raisonnent comme vous... et qui nous appellent à l'aide quand le client gu... sur sa base de production... en l’occurrence 95% du temps ils se serraient contentés de suivre les règle élémentaires prônées ici il n'y aurait pas eu de soucis...

Bien cordialement