j'ai créé plusieurs rappports en utilisant des vues (pour re-création es
flowfields) prélablement créées dans SQL. On m'a dit, que pour des soucis de
performance, il était préférable de ne pas utilisées de vue lorsque l'on créé
des rapports .Il vaut mieux tout faire ans visual studio.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romelard Fabrice [MVP]
Bonjour,
Très franchement, je ne comprends pas bien pourquoi ceci a été dit. A mon sens, SSRS est une interface envoyant des requêtes au moteur relationnel (ou décisionnel) et de ce fait, n'a aucune particularité quand à la gestion interne de SQL Server. Ceci pour dire que les règles de développement s'appliquent exactement de la même façon que pour les autres application ASP.NET.
Ainsi, il faut préférer les procédures stockées et les vues aux requêtes en direct dans Visual Studio.
De plus, cela permet une certaine liberté en cas de modification de la sélection des données à afficher (ajout d'un filtre qui n'existait pas auparavant par exemple) simplement par la modification de la vue ou SP.
Si d'autres ont des arguments.
-- Cordialement.
Romelard Fabrice [MVP]
"Crackers" a écrit dans le message de news:
Bonjour,
j'ai créé plusieurs rappports en utilisant des vues (pour re-création es flowfields) prélablement créées dans SQL. On m'a dit, que pour des soucis de performance, il était préférable de ne pas utilisées de vue lorsque l'on créé des rapports .Il vaut mieux tout faire ans visual studio.
Qu'en pensez vous ?
-- Crackers
Bonjour,
Très franchement, je ne comprends pas bien pourquoi ceci a été dit.
A mon sens, SSRS est une interface envoyant des requêtes au moteur
relationnel (ou décisionnel) et de ce fait, n'a aucune particularité quand à
la gestion interne de SQL Server.
Ceci pour dire que les règles de développement s'appliquent exactement de la
même façon que pour les autres application ASP.NET.
Ainsi, il faut préférer les procédures stockées et les vues aux requêtes en
direct dans Visual Studio.
De plus, cela permet une certaine liberté en cas de modification de la
sélection des données à afficher (ajout d'un filtre qui n'existait pas
auparavant par exemple) simplement par la modification de la vue ou SP.
Si d'autres ont des arguments.
--
Cordialement.
Romelard Fabrice [MVP]
"Crackers" <Crackers@discussions.microsoft.com> a écrit dans le message de
news: 2FA7635F-B14D-4387-B69A-79B96DAED83B@microsoft.com...
Bonjour,
j'ai créé plusieurs rappports en utilisant des vues (pour re-création es
flowfields) prélablement créées dans SQL. On m'a dit, que pour des soucis
de
performance, il était préférable de ne pas utilisées de vue lorsque l'on
créé
des rapports .Il vaut mieux tout faire ans visual studio.
Très franchement, je ne comprends pas bien pourquoi ceci a été dit. A mon sens, SSRS est une interface envoyant des requêtes au moteur relationnel (ou décisionnel) et de ce fait, n'a aucune particularité quand à la gestion interne de SQL Server. Ceci pour dire que les règles de développement s'appliquent exactement de la même façon que pour les autres application ASP.NET.
Ainsi, il faut préférer les procédures stockées et les vues aux requêtes en direct dans Visual Studio.
De plus, cela permet une certaine liberté en cas de modification de la sélection des données à afficher (ajout d'un filtre qui n'existait pas auparavant par exemple) simplement par la modification de la vue ou SP.
Si d'autres ont des arguments.
-- Cordialement.
Romelard Fabrice [MVP]
"Crackers" a écrit dans le message de news:
Bonjour,
j'ai créé plusieurs rappports en utilisant des vues (pour re-création es flowfields) prélablement créées dans SQL. On m'a dit, que pour des soucis de performance, il était préférable de ne pas utilisées de vue lorsque l'on créé des rapports .Il vaut mieux tout faire ans visual studio.
