Discussion :

[LeHibou2]

Bonjour à tous,

J'ai créé une requête qui sélectionne des données et les affiche ou non, je créé des sommes et tout un tralala.

Ma requête me permet de tout tirer et ensuite, je masque les données avec excel/calc.

Je me dis une chose : créer autant de vue que nécessaire surchargerait certainement le serveur (charge possible limitée) alors qu'avec ma feuille de calcul, cela se fait tranquillement.

Est-ce qu'on voit ici la limite des vues dans le sql ?

Quand bien même je ne fais pas de traitement, si je précise toutes les conditions et affichages dans la requête, à quoi me sert ma vue ?

Il n'y a pas de sécurité supplémentaire apportée, les structures de tables ne changent jamais et au pire, je corrige la requête.

Je ne saisis pas pourquoi on se prend la tête à créer des vues spécifiques alors que des requêtes spécifiques suffisent.

Vous pouvez m'expliquer ?

Merci à vous,

LeHibou

[CinePhil]

Si tu agis tout seul sur ta propre base de données, tu peux te passer des vues et te contenter de requêtes que tu maîtrises totalement.

L'intérêt des vues est de faire abstraction de la structure de la BDD pour le développeur de l'application qui utilise la BDD.

L'autre intérêt majeur est un meilleur contrôle de l'accès aux données piloté par le SGBD en autorisant l'utilisateur X seulement un accès en lecture à certaines vues et pas à d'autres. C'est très important en cas d'utilisation de certaines données issues de tables contenant des données confidentielles.

Par exemple, un ensemble de tables pour la gestion du personnel peut contenir des données confidentielles accessibles seulement aux membres du service des ressources humaines mais des données issues de cet ensemble pourraient servir à délivrer par exemple l'annuaire interne du personnel accessible à tout le monde. Pour être sûr que les données confidentielles soient réservées, on crée un utilisateur de la BDD auquel on accorde seulement le droit sur la vue de l'annuaire.

Pour plus d'infos sur les vues, voir le chapitre que SQLPro leur consacre.

[LeHibou2]

Merci pour cette réponse CinePhil,

Mon point de vue se place essentiellement dans le cadre d'un reporting : une exécution automatique d'un script envoyé à des collaborateurs.

La requête est déjà prévue à l'avance et le csv qu'ils reçoivent ne contient aucune info qui ne leur est pas destinée.

Dans ce cas, ils ne reçoivent que les données qui leurs sont destinées.

Mais la question est de savoir ce qui consomme le moins pour le serveur :

- Chaque groupe reçoit le résultat d'une requête calculée spécifiquement pour lui (un groupe, une requête spécifique)
- Chaque groupe reçoit la vue d'une super requête globale calculée donc pour tous mais à la vue adaptée aux différents groupes. (une super requête partagée en vue)

C'est une question qui se positionne essentiellement au niveau perf serveur et charge.

Votre avis ?

Merci à vous,

A bientôt

Le Hibou2

[punkoff]

La question ne se pose même pas.

D'un point de vue réseau, accès disque, accès mémoire, bref ressources utilisées, qu'est-ce qui est le mieux :
- ramener les données utiles + plein de données inutile
- ramener les données utiles

Ca me fait penser, lors de mon dernier projet un developpeur avait ramener côté applicatif une table entière pour faire ces agrégations avec du code Java ...

[sevyc64]

Il faut aussi garder à l'esprit que sur des SGBD type serveur (SQLServer, Oracle, etc) il faut faire un maximum de manipulation des données (agrégations, filtres, tris, jointures, ...) coté SGBD. Ça sera généralement bien plus rapide que de le faire ensuite par code.

[Rei Ichido]

La question ne se pose même pas.

D'un point de vue réseau, accès disque, accès mémoire, bref ressources utilisées, qu'est-ce qui est le mieux :
- ramener les données utiles + plein de données inutile
- ramener les données utiles

Ca me fait penser, lors de mon dernier projet un developpeur avait ramener côté applicatif une table entière pour faire ces agrégations avec du code Java ...

Je pense (mais je peux me tromper) que la demande était plutôt du genre "Est-ce qu'il vaut mieux avoir :"

Code :

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

SELECT colonnes FROM vue_globale WHERE conditions

que

Code :

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

SELECT colonnes FROM requete -- avec la requete qui comprend le code de la vue + les conditions supplémentaires

. Si c'était bien la question, alors la réponse est que le SGBD va gérer les deux cas de la même façon.
Une différence est quand même que quand on écrit la requête directement, on peut mettre en amont des conditions dans les sous-requêtes. En théorie si on ne le fait pas mais qu'appliquer le filtre en amont est intéressant, le SGBD le fait ; en pratique il ne le fait pas toujours (notamment si les stats ne sont pas bien à jour).

[CinePhil]

Mais la question est de savoir ce qui consomme le moins pour le serveur :

- Chaque groupe reçoit le résultat d'une requête calculée spécifiquement pour lui (un groupe, une requête spécifique)
- Chaque groupe reçoit la vue d'une super requête globale calculée donc pour tous mais à la vue adaptée aux différents groupes. (une super requête partagée en vue)

Si je recoupe avec ce qui a été dit précédemment :

je masque les données avec excel/calc

Je crois comprendre que les deux alternatives sont celles-ci :
1) Une vue utilisée pour tous les groupes et une moulinette du tableur qui ne donne à voir à chaque groupe que ce qui le concerne.
2) Autant de requêtes personnalisées que de groupes.

La moulinette du tableur travaille t-elle une seule fois sur les données importées ou est-elle mise en route à chaque fois qu'unh membre d'un groupe veut ses informations ?
Les données sont-elles importées à la demande de chaque utilisateur ou bien seulement périodiquement pour tout le monde ?

Bref, il faudrait décrire un peu plus le processus car la solution adéquate pour vous indiquer ce qui nous semble la solution la plus adéquate.