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]

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.

[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