Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier...
Supposons que tu es une très grosse base, ou pleins de bases, qui contiennent pleins d'éléments différents en fonction des ventes, de la techniques, des investisseurs, des fournisseurs, des clients etc.
Supposons maintenant que quelqu'un veuille faire du reporting avec des données consolidées, parfois par année ou par mois ou encore par produit pour chaque sous ensemble des données précités.
Genre un top ten des clients les plus rentables pour le mois de mars 2015, ou une liste des taux d'incidents par produit en fonction du fournisseur.
Tu as le choix entre trois solutions :
- Choix 1) un super cube OLAP, mais ça ne marche que si les types de données demandés par la direction ne changent pas trop - sinon il faut refaire tous les rapports le jour ou on décide qu'il faut ajouter le respect ou non de ISO-TrucBidule sur tous les déploiements.
Choix 2) 8000+ vues, une pour chaque découpe. C'est la teuf à la maintenance aussi.
Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.
Par exemple une fonction getStatsBy(< col >) qui fournira toutes les infos consolidées possibles et imaginables avec consolidation sur la colonne spécifiée.
Clairement les procédures stockées ne doivent jamais contenir de logique métier, mais elles peuvent être extrêmement pratiques même sans ça.
[^] # Re: Facile!
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 10.
Supposons que tu es une très grosse base, ou pleins de bases, qui contiennent pleins d'éléments différents en fonction des ventes, de la techniques, des investisseurs, des fournisseurs, des clients etc.
Supposons maintenant que quelqu'un veuille faire du reporting avec des données consolidées, parfois par année ou par mois ou encore par produit pour chaque sous ensemble des données précités.
Genre un top ten des clients les plus rentables pour le mois de mars 2015, ou une liste des taux d'incidents par produit en fonction du fournisseur.
Tu as le choix entre trois solutions :
- Choix 1) un super cube OLAP, mais ça ne marche que si les types de données demandés par la direction ne changent pas trop - sinon il faut refaire tous les rapports le jour ou on décide qu'il faut ajouter le respect ou non de ISO-TrucBidule sur tous les déploiements.
Choix 2) 8000+ vues, une pour chaque découpe. C'est la teuf à la maintenance aussi.
Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.
Par exemple une fonction getStatsBy(< col >) qui fournira toutes les infos consolidées possibles et imaginables avec consolidation sur la colonne spécifiée.
Clairement les procédures stockées ne doivent jamais contenir de logique métier, mais elles peuvent être extrêmement pratiques même sans ça.