|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||||||
|
Nouveau Membre du Club
![]() Loïc BernardConsultant en Business Intelligence Inscription : avril 2008 Messages : 44 ![]() |
Bonjour,
Toujours sur ma problématqiue des Event je reviens vers vous pour un nouveau problème. J'ai besoin à partir de ma table event d'obtenir un total cumulé et un pourcentage cumulé. L'objectif étant de faire un graphe dans SSRS. Je m'explique : Voici le contenu de ma table Event (code de création et d'insertion plus bas) Pour info le IdTypeEvent est l'identifiant du type d'evenement par exemple le 42 correspond à un evenement de type"surchaufe de la cuve", 3 correspond à "Pression trop Elevée" Code :
Code :
J'ai créé un script qui me permet d'obtenir ceci mais(car il ya un mais) il ne me convient qu'à moitié car d'une part je le trouve un peu "tordu" et d'autre part je passe par une table temporaire intermédiaire Voici ce script : Code :
Code :
Merci d'avance Loic |
||||||||
|
|
00
|
|
|
#2 | ||
![]() ![]() ![]() Frédéric BROUARDExpert SGBDR & SQL Inscription : mai 2002 Messages : 10 954 ![]() |
Pourquoi utiliser une table temporaire ? Cela ne sert à rien qu'a grever les perf !
Pourquou faire plusieurs CONVERT alors que CAST est la norme SQL et se trouve être plus rapide ? Voici une première solution : Code :
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
||
|
00
|
|
|
#3 | ||
|
Nouveau Membre du Club
![]() Loïc BernardConsultant en Business Intelligence Inscription : avril 2008 Messages : 44 ![]() |
Merci pour ta réponse,
Citation:
Citation:
Quelles est la Différence entre Numeric et DECIMAL? pourquoi avoir les Float et pas partout des décimal? Pourquoi DECIMAL(16,2) et pas DECIMAL(5,2) ? Bien à toi, Loic |
||
|
|
00
|
|
|
#4 |
|
Nouveau Membre du Club
![]() Loïc BernardConsultant en Business Intelligence Inscription : avril 2008 Messages : 44 ![]() |
RE,
Je viens de me rendre compte de quelque chose de très embetant. En fait, je travaille Pour la production d' une Enorme entrerpise. cette entreprise a des dizaines et des dizaines (voir centaines) d'unités de production répartis partout dans le monde. Chaque unité de production a ses serveurs et ses bases de données indépendament des autres. Le problème est que d'une unité à l'autre la version de MS SQL SERVER n'est pas la meme et que ROW_NUMBER en SQL 2000 ca existe pas Que pourrais je avoir comme autre solution que de passer par une table intermédiaire pour remplacer ce ROW_NUMBER? Merci d'avance Bien à toi, Loic |
|
|
00
|
|
|
#5 |
![]() ![]() Alexandre ChemlaConsultant en Business Intelligence Inscription : février 2006 Messages : 1 773 ![]() |
Ce n'est plus en T-SQL, mais SSRS à la possibilité de faire des calculs de sommes cumulées.
Il faut regarder d'une expression dans ce genre : Code :
RunningValue(FIELDS!valeur.Value, Sum, "MonGroupement")
__________________
Alexandre Chemla - Consultant MS BI chez Masao |
|
|
00
|
|
|
#6 | ||
![]() ![]() ![]() Frédéric BROUARDExpert SGBDR & SQL Inscription : mai 2002 Messages : 10 954 ![]() |
Pour palier à l'absence de ROW_NUMBER il faut faire une non équijointure avec comptage.
En gros : Code :
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
||
|
00
|
|
|
#7 | |||||||||||||||||
|
Membre éprouvé
![]() ![]() Hamid MIRAIngénieur développement logiciels Inscription : septembre 2003 Messages : 177 ![]() |
Citation:
Extrait du BOL : decimal[ (p[ ,s] )] et numeric[ (p[ ,s] )] Valeurs de précision et d'échelle fixes. Lorsque la précision maximale est utilisée, les valeurs valides sont comprises entre - 10^38 +1 et 10^38 - 1. Les synonymes ISO de decimal sont dec et dec(p, s). numeric est fonctionnellement équivalent à decimal. Conclusion : Sous SQL Server decimal(p,s) et numeric(p,s) sont des synonymes, et il n'y a aucune différence entre les 2 types. Certains vont même jusqu'à dire que le terme numeric est déprécié et qu'il vaut mieux utiliser uniquement le terme decimal.. Je n'ai trouvé aucune trace, dans le BOL, de cette affirmation (?), Personnellement, sous SQL Server, je n'utilise jamais, le terme numeric(p,s), j'utilise uniquement le terme decimal(p,s). 2 - Pourquoi avoir les Float et pas partout des décimal ? Sous SQL Server, lorsqu'un opérateur (exemple +, - * / etc..) combine 2 valeurs (ou expressions) de type différents (exemple, int et float, .), il y a une conversion implicite du type ayant la priorité la plus faible vers le type ayant la priorité la plus forte (Voir en fin de ce poste, les différents niveaux de priorités) . Exemple: Code SQL :
Code SQL :
Lorsque les 2 valeurs (ou expressions) ont le même type de données, le résultat de l'opération a également ce type de données. Exemple : Code SQL :
Code SQL :
Exemple: Code SQL :
Resultat : Msg*8115, Niveau*16, État*2, Ligne*5 Une erreur de dépassement arithmétique s'est produite lors de la conversion de expression en type de données int. Remarquez que l'erreur se produit à la ligne 5, c.à.d SELECT @i1 + @i2 AS Resultat Pour revenir à ta question, le CAST en float s'avère nécessaire pour calculer le pourcentage. En effet, sans le CAST en float, le résultat serait faux, comme le montre l'exemple ci-dessous. Code SQL :
Code SQL :
Voilà ce qui explique l'utilisation des transtypage en float dans la CTE de SQLPro. Code SQL :
SELECT CAST(Sum(CptEvent) AS FLOAT .... 3 - Pourquoi DECIMAL(16,2) et pas DECIMAL(5,2) ? Effectivement dans ce cas très précis on aurait pu utiliser decimal(5,2) au lieu de decimal(16,2) à condition de démontrer mathématiquement que quelque soit le contexte, l'expression pourcentage définie dans la CTE, varie entre 0 et 100. Ce qui semble être est le cas (encore faut-il le démontrer !) Le choix decimal(16,2) était surement une précaution prise par SQLPro pour exprimer le résultat tout en minimisant au maximum les risque de dépassement de capacité. Ce qui est, d'après moi, un choix raisonnable. La prudence dans son paroxysme, pourrait même nous inciter à utiliser decimal(38,2). De même (ou dans le même ordre), si d'aventure, le nombre d'enregistrement de ta table Event dépasse 2 147 483 647 (!) , il te faudra dans ce cas : - Utiliser la fonction d'agrégation COUNT_BIG(*) au lieu de COUNT(*) - Et, utiliser Sum(CAST(CptEvent AS BIGINT)) au lieu de Sum(CptEvent) ----------------------------------------------------------------- Liste des niveaux de priorités (le niveau 1 étant le plus haut niveau de priorité) : Code X :
|
|||||||||||||||||
|
|
10
|
Copyright © 2000-2012 - www.developpez.com