Discussion :

[helrick]

Bjr à tous

Dans le temps j'ai travaillé avec une table calendrier sous MSSQL 2005 et une appli asp qui affichait le calendrier d'une année au choix à imprimer.

En PROD plutot que d'avoir à s'embetter à gérer les formats de date, on créé et fait circuler dans les BD un ID de date (correspond selon une matrice à un jour, une semaine, un mois, un trimestre, un semestre, une année...).

Ex : Jeudi 1er juilet 2010 : ID = 3821

Ce que je n'arrive pas à faire c'est de monter une SP surtout qui saura inclure ou pas les années bixestiles et le bon nombre de jours par mois...
Comment calculer tout ça ?

Si vous avez une idée, dites moi
Merci

[spdev666]

Bonjour,

Je ne suis pas sur de bien avoir compris, mais si le besoin est de remplir une table avec l'ensemble des jours du calendrier sur plusieurs années, j utiliserais comme base de travail une requete qui me renvoi tout ça (voir discution suivante : http://www.developpez.net/forums/d94...e-table-temps/)

Ensuite, il n y a plus qu a extraire le numero du jour, du mois, de l année, ... de la date généré par la requete

[mnitu]

...En PROD plutot que d'avoir à s'embetter à gérer les formats de date, on créé et fait circuler dans les BD un ID de date (correspond selon une matrice à un jour, une semaine, un mois, un trimestre, un semestre, une année...).
...

Une date n'a pas de format comme tous autre type de données par ailleurs! Les format servent seulement à la conversion entre le type chaine de caractères et le type date et vice versa.
L'idée en soit de stocker un calendrier n'est pas séduisante sauf cas très particulier.

...

Ce que je n'arrive pas à faire c'est de monter une SP surtout qui saura inclure ou pas les années bixestiles et le bon nombre de jours par mois...
Comment calculer tout ça ?

Vous perdez votre temps. Oracle a tous qu'il faut pour gèrere ça, lisez la documentation.

[helrick]

Non ce n'est pas de la perte de temps croyez moi.
J'ai déjà travaillé avec ce système :
1- il est portable sous n'importe quel système
2- il évite de manipuler des formats de date chiants.
3- D'un point de vue d'analyse décisionnelle, comparer 2 dates avec un entier sur des milliards de lignes pr mon besoin actuel.

C'est loin d'etre inéfficace.
Merci pr vos réponses

[McM]

Il y a un autre post en cours là dessus :http://www.developpez.net/forums/d94...e-table-temps/

par contre, mon client a une base BO, et a tout géré par table de calendrier.. l'ID étant la date julienne.
Et je peux dire que.. c'est super chiant !
Parce que pour faire des stats sur des périodes de date, ça oblige à des sous select pas top.

[Waldar]

Je rejoins les avis de mes camarades.
N'utilisez pas un ID pour avoir une date, utilisez une date, ça vous évitera bien des problèmes.

Si vos données sont bien typées date, vous n'avez pas de format à gérer, vous pouvez heureusement les comparer directement !

La création de la table calendrier telle qu'indiquée dans l'autre sujet ne prend que quelques millisecondes, c'est donc facilement portable également.
Il n'y a pas d'histoire de format puisque votre clef primaire sera une date.
Ce sera plus efficace que n'importe quelle moulinette que vous pourrez inventer.

[helrick]

Il y a un autre post en cours là dessus :http://www.developpez.net/forums/d94...e-table-temps/

par contre, mon client a une base BO, et a tout géré par table de calendrier.. l'ID étant la date julienne.
Et je peux dire que.. c'est super chiant !
Parce que pour faire des stats sur des périodes de date, ça oblige à des sous select pas top.

Bjr,
Déjà il faut vous imprimer la matrice des dates pour travailler.
Ensuite ce système est absolument plus pratique en termes de performance serveur pour les requêtes. On se prend pas la tête.
Cela arrive qu'on transporte des univers sous d'autres environnements de BD, si l'environnement SQL cible de production produit ce DateId parfait l'installation est prise en charge. C'est nikel
Enfin, je trouve que ce système évite le format des champs de type date, timestamp... différent, pr ne rien arranger, sous chaque système.
A mon sens c'est un luxe et un confort de travail pour produire des axes d'analyse temporel. Cette table de date est une nomenclature de l'espace temps : un réservoir d'axes. Les contrôleurs de gestion en raffolent.

Aller, a bientot

[helrick]

Je rejoins les avis de mes camarades.
N'utilisez pas un ID pour avoir une date, utilisez une date, ça vous évitera bien des problèmes.

Si vos données sont bien typées date, vous n'avez pas de format à gérer, vous pouvez heureusement les comparer directement !

La création de la table calendrier telle qu'indiquée dans l'autre sujet ne prend que quelques millisecondes, c'est donc facilement portable également.
Il n'y a pas d'histoire de format puisque votre clef primaire sera une date.
Ce sera plus efficace que n'importe quelle moulinette que vous pourrez inventer.

Je suis +/- d'accord avec vous.
Je précise jusque que ces dateid ne me servent que pour la partie décisionnelle de mon travail. Comme je l'ai dit précédemment, lorsque que vous offrez la possibilité de découper un C.A par de multiples dimensions opérationnelles et Grace à plusieurs repères dans le temps : ça fait plaisir à la direction d'avoir à dispo la finesse du détail.

Et sachant que la BD manipule des entiers pour parler de dates : c'est un gain de temps por moi. Sous sql server surtout, combien de fois je me suis retrouvé avec des dates de multiples formats et bonjour la galère pour monter des analyses là dessus.

Merci à tous de donner vos avis.
Vos arguments sont bien positionnés pour etre débattus.

[Waldar]

En réalité les dates sont la combinaison de deux nombres : la partie entière pour gérer les jours, une partie décimale pour gérer les heures / minutes / secondes.

Donc à utiliser un entier, vous ne gagnez pas vraiment en performance.

L'intérêt d'utiliser les types dates natifs des bases de données c'est que vous n'avez pas à redévelopper les points suivants :

• années bissextiles
• calcul des semaines ISO ou pas ISO
• calcul avec un nombre de mois en unité

Et sûrement d'autres.

Avec vos ID, comment répondez-vous à la question suivante :
Le CA des six derniers mois.
Le CA en YTD (year to date : la somme du CA du 1er janvier à aujourd'hui).
La comparaison avec les quatre derniers YTD.

Vous allez devoir faire des jointures avec votre calendrier pour répondre à ces questions.
Avec le type date, pas besoin.
Et il offre exactement les mêmes possibilités d'offrir plusieurs axes d'analyse (calendaire, fiscal, prise en compte des jours ouvrés etc.).

[helrick]

Bjr
Je réponds à ce genre de questions tous les jours.
J'ai mon calendrier codé par jour sous les yeux. Et je fais ma requête avec comme filtres where date_conso between 3741 annd 3910.
Je précise quand même que ce genre de formatage est plus utilisé pour la partie décisionnelle des BD.
Le jour où on décide qu'il faut analyser l'évolution du C.A par trimestre ou par semaines, pareil ma nomenclaturee st montée ! Pas besoin de perdre 100 ans à employer des fonctions de découpage...bref

Et quand je dois exécuter la même requete, avec les memes champs mais sous des environnements différents : je ne m'embette pas à tout refaire..

Enfin je gère un entier en BD en terme de performance ya pas mieux.
A+

[Waldar]

Vous avez faux sur toute la ligne !

Et je fais ma requête avec comme filtres where date_conso between 3741 and 3910.

Quelle horreur : illisible, propriétaire.
Personne ne relit votre code je suppose ?
C'est le genre de requête qu'en tant que consultant je snipe à vue, et je ne suis pas le seul.

Le jour où on décide qu'il faut analyser l'évolution du C.A par trimestre ou par semaines, pareil ma nomenclature est montée ! Pas besoin de perdre 100 ans à employer des fonctions de découpage...

Et bien moi aussi, pour le moment j'ai neuf axes d'analyse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
select day, day_number, week_iso, month, quarter, year,
       fiscal_month, fiscal_quarter, fiscal_year, fg_holiday
  from calendar
 where day = date '2010-07-06';
 
DAY        DAY_NUMBER WEEK_ISO MONTH  QUARTER YEAR FISCAL_MONTH FISCAL_QUARTER FISCAL_YEAR FG_HOLIDAY
06/07/2010 2          201027   201007 2010Q3  2010 201007       2011Q2         2011        0

Et quand je dois exécuter la même requête, avec les mêmes champs mais sous des environnements différents : je ne m'embête pas à tout refaire...

Le type date est plus universel que votre entier non ?
Donc je ne vois pas en quoi ce serait moins portable !

Enfin je gère un entier en BD en terme de performance ya pas mieux.

Sur Oracle les différences sont minimes.

Si je devais faire une analogie, vous réinventez une roue ronde en roue carrée sous prétexte qu'elle se range mieux dans les cartons.

[McM]

Cela dit, on sort du contexte initial : Est ce que le sujet du post (table calendrier) est résolu ou pas ?

[helrick]

Chacun sa méthode.
Si les votre fonctionnent tant mieux.
Mes systèmes de production sous mssql server tournent avec ce système.
Peut-etre que sous oracle on en ait moins besoin.

Sujet résolu.
Merci de vos contributions.