Infirmation de l'intérêt de la vue

Version imprimable

15/02/2012, 10h01
LeHibou2

Infirmation de l'intérêt de la vue

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
15/02/2012, 11h44
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.
15/02/2012, 12h17
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
15/02/2012, 13h38
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 ...
15/02/2012, 13h53
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.
15/02/2012, 14h52
Rei Ichido

Citation:

Envoyé par 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 ...

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

Code:

SELECT colonnes FROM vue_globale WHERE conditions

que

Code:

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).
15/02/2012, 15h13
CinePhil

Citation:

Envoyé par LeHibou2

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 :

Citation:

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.
15/02/2012, 16h58
LeHibou2

Oui bien sûr, je vais préciser : oubliez le point avec Excel où je masque les colonnes. J'ai progressé depuis ce matin.

Effectivement, je cherche à gagner le maximum de temps.

Je ne suis pas développeur mais entrepreneur; et chaque seconde passée à demander des commandes et arranger des documents doit être un investissement rentable.

Je cherche l'optimum de performance, préservant donc mon serveur (plusieurs sociétés à mon actif, je ne peux pas me permettre n'importe quoi).

Cet après midi j'ai eu un bon ROI : la commande GROUP BY ... WITH ROLLUP est vraiment puissante (je trouve), puisqu'elle me permet de créer des reports très précis et adaptés aux groupes.

Je précise la question qui était la mienne. Vaut-il mieux que

- Je prépare mes requêtes en amont + cron + envoi mail du csv pour traitement/présentation données que je remail à un groupe particulier. Pas de données superflues accessibles (grâce à la requête qui gère les SELECT)

- Je prépare une requête monstrueuse qui regroupe toutes les infos de tous les groupes et je créé autant de vue que de groupes. (Je ne vois pas comment automatiser cela honnêtement).

La différence est dans le traitement requête perso ou vue perso. Je cherche l'optimum ressource.

Merci à vous,

LeHibou2
15/02/2012, 17h06
CinePhil

Citation:

Je précise la question qui était la mienne. Vaut-il mieux que

- Je prépare mes requêtes en amont + cron + envoi mail du csv pour traitement/présentation données que je remail à un groupe particulier. Pas de données superflues accessibles (grâce à la requête qui gère les SELECT)

- Je prépare une requête monstrueuse qui regroupe toutes les infos de tous les groupes et je créé autant de vue que de groupes. (Je ne vois pas comment automatiser cela honnêtement).

Ça reste trop imprécis.
Quel est le besoin réel ?
Délivrer des données à la demande de chaque utilisateur ?
Faire un rapport préformaté identique pour tous les groupes mais avec les données qui concernent chaque groupe ?
Et puis d'ailleurs, qu'appelez-vous "groupe" ?
Pourquoi passer par du CSV pour le retraiter au lieu de traiter directement les données dans le SGBD ou à l'aide d'un programme adéquat ?
Quel logiciel fait la présentation des données ?
La présentation est-elle la même pour tous les utilisateurs ?

Bref, lisez la phrase en bleu de ma signature et appliquez son principe.

Et puisque vous avez posté dans le forum "Langage SQL", respectez ses règles ; ça facilitera nos réponses.
15/02/2012, 17h21
LeHibou2

Toute colère est une perte d'énergie.

Je vais me débrouiller. Je reste néanmoins convaincu que les vues sont du travail superficiel.

Inutile de provoquer des accès d'autorité pour cela.

Cordialement

[EDIT]
Je m'amende. Les vues seront utiles dans des applications développées, mais pas du tout dans mon cas.

Mea culpa et bonne continuation à tous,

LeHibou2
16/02/2012, 17h15
SQLpro

outre mes bouquins sur SQL, ayant écrit tant de choses sur les vues et passant mon temps depuis plus de 20 ans à en défendre l'usage, je me permet de vous donner quelques conseils :

1) les vues dont des interfaces qui permettent de conserver votre code applicatif intact, même si vous modifiez la structure de vos tables, ce qui vous arrivera tôt ou tard.
Exemple : une table trop grosse pourra être partitionnée de manière verticale ou horizontale et alors il ne vous suffira plus qu'a redéfinir votre vue plutôt que de récrire toutes vos applications.

Sachez d'ailleurs que toutes les applications devraient être écrites uniquement à partir des vues et non des tables. Ces vues constituent l'essentiel du modèle externe de données ou MED.
Voir le livre de Crhistian Soutou et moi même qui va paraître dans 1 mois chez Eyrolles

2) les vues permettent un meilleure mise en cache des plans de requête. En effet lorsque l'on écrit une requête la moindre différence d'un version à l'autre de l'écriture provoque la recompilation des plans de requête. or une vue n'est que très rarement récrite... En tout cas bine moins qu'une requête adhoc.

3) certains SGBDR permettent de créer des vues matérialisées. Cela permet des performances phénoménales dans certains cas.
En principe une vue ne contient pas de données. mais au contraire d'une vue ordinaire, une vue indexées (ou matérialisées) est une vue qui contient des données calculées automatiquement par le SGBDR.
C'est particulièrement intéressant lorsque l'on a des calculs d'agrégats,(SUM, COUNT...) notamment pour des calculs de chiffre d'affaire comme cela semble être votre cas.
J'ai montré dans cette étude, comment optimiser par un facteur 16 000 (SEIZE MILLE) une requête calculant un COUNT sur une table de 125 millions de lignes...
http://sqlpro.developpez.com/optimisation/indexation/
Seul problème, les pseudo SGBDR comme MySQL ou encore PostGreSQL n'intègrent pas ce genre de technique.

Il y aurait encore bien d'autres choses à dire... je vous laisse lire mon site comme mes bouquins !

A +