Discussion :

[Worldofdada]

Bonjour,

Je suis novice avec SQL Server et j'aurais une petite question concernant les performances d'une idée ...

J'ai une table TOTO, contenant beaucoup d'enregistrements.
Chaque enregistrement de la table TOTO possède 2 champs de "droit".

J'ai également une table UTILISATEUR, contenant mes utilisateurs et je peux, avec d'autres tables récupérer les 2 champs de droit.

Je souhaites récupérer, pour un utilisateur, l'ensemble de ses données TOTO (restreint avec 1 des 2 champs "droit").

Je pensais faire une vue utilisant toutes les tables avec les liaisons.
Le nombre d'enregistrement de cette vue serait la somme des utilisateurs - TOTO.
C'est à dire qu'elle contiendrait autant d'enregistrement que j'ai de liaison utilisateur - TOTO.

Ensuite, lorsque je ferais une requetes, j'aurais juste a faire un where ID_utilisateur = 127.

Seulement j'ai un peu peur sur les performances.
SQL Server construit il d'abord l'intégralité de la vue avant d'appliquer le where ou part il du where pour construire les données de la vue ?


Sinon, je pensais peut etre faire une fonction me renvoyant des tuples (en supposant que c'est possible).


En espérant que vous aurez pu me comprendre, quelqu'un aurait il un avis, une solution ?

Merci d'avance
Worldofdada

[SQLpro]

une seule requete sera toujours 10, 100 ou 1000 fois plis rapide que tout qutre code.

A +

[Worldofdada]

Imaginons que j'ai une table CLIENT.
Un utilisateur connecté peut voir certains clients, par rapport a ses restrictions.

Si je fais une vue vClient, j'aurais en contenu :

Code :

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

1
2
3
4
5
6
idClient1   nomClient1   adresseClient1   utilisateur1
idClient2   nomClient2   adresseClient2   utilisateur1
idClient3   nomClient3   adresseClient3   utilisateur1
idClient1   nomClient1   adresseClient1   utilisateur2
idClient2   nomClient2   adresseClient2   utilisateur2
idClient2   nomClient2   adresseClient2   utilisateur3

Le nombre d'enregistrements de cette vue sera la somme de tous les clients visibles pour tous les clients.

Si l'utilisateur 1 se connecte, il me reste plus qu'a appeler la vue avec un WHERE utilisateur = utilisateur1.

Pour ce cas de figure, ma question est :
SQL Server va t'il reconstruire intégralement la vue avant d'appliquer le where ?
Ou le construction de la vue va directement tenir compte de mon where ?


Car dans le 1er cas, SQL Server va devoir construire une vue de plusieurs centaines de milliers d'enregistrements.
Dans le 2eme cas, il ne construit la vue avec seulement mes 3 enregistrements.

Savez vous comment fonctionne SQL Server afin de savoir si cette méthode est viable ou non ?
En gros, puis je utiliser cette méthode, où dois je faire une seule requete (la vue me permet de décomposer cette meme requete en 2 petites) ?

Merci

[SQLpro]

Revisez vos cours ou apprenez SQL, il n'y a pas de donnees dans une vue !

Que vous fassiez une requete directe ou une vue, c'est la meme chose. Les donnes sont dans les tables et nulle part ailleurs !

A +

[Worldofdada]

Je pense que tu ne comprends pas du tout ma question.

Je sais très bien qu'il n'y a aucune donnée dans une vue.
Ma question n'a rien a voir avec du SQL mais uniquement avec SQL Server.
Je ne demande pas comment faire, je demande simplement la méthode de fonctionnement de SQL Server.

Quand on appelle, dans une requete, une vue : SQL Server CONSTRUIT la vue (j'ai bien dit construit, et pas rempli)

En admettant avoir une vue nommé vCLIENT_RECENTS.
La vue contient tous les clients ajoutés il y a moins de n jours.

Si je fais SELECT * FROM vCLIENT_RECENTS WHERE ID_Client = 5 :
1 - est ce que la vue va etre CONSTRUITE avec tous les enregistrements de la vue PUIS filtrée avec la contrainte ID_client = 5 ?
2 - est ce que la vue va etre directement CONSTRUITE avec la contrainte ID_client = 5 ?

Mon exemple est stupide mais ce n'est pas la question posée.
C'est un exemple, et ca n'a rien avoir avec mon cas d'utilisation.

C'est une question sur les performances de SQL Server, pas sur du SQL.

Encore merci
Worldofdada

[Worldofdada]

J'ai fais un test mais j'ai pas vu de réelle différence ... mais j'étais en local.

Quelqu'un n'a pas de réponse ?
Merci

[Crotte]

Selon moi (et seulement moi...) un where sur une vue n'est pas une bonne solution sur des tables volumineuses... il est obligé de l'exécuter en deux fois... forcément.

Pourquoi ne fais-tu pas une procédure stockée avec comme paramètre ton utilisateur ? Cela te permettrais de l'ajouter directement dans ton select.

Code :

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

1
2
3
4
5
6
 
create procedure maPS @user int as
SELECT * 
FROM CLIENT 
inner join DROIT on dr_Client = ID_Client
WHERE ID_Client = @user

Si l'utilisation d'une procédure ne te gêne pas, passe par là, tu y gagnera toujours en perf !

Et pour rebondir sur l'une des réponses plus haut... de SQLpro

une seule requete sera toujours 10, 100 ou 1000 fois plis rapide que tout qutre code.

Qu'entends-tu par 'une seule requête' ?

Parce que, pour l'avoir testé, l'utilisation de tables temporaires s'avère beaucoup plus performant que des select imbriqués, par exemple...

[SQLpro]

IL N'Y A ACUCUNE DIFFERENCE EN MATIERE D'EXECUTION ENTRE UNE VUE ET UNE REQUÊTE ...
est-ce clair ?

que vous fassiez le fitre sur la table ou sur la vue le plan d'exécution est le même.

Encore une fois il n'y a pas de matérialité dans une vue, c'est une requête SQL à laquelle, si l'on applique des filtres, viendront se rajouter lesdits filtres !

A +

[Worldofdada]

Ok merci

[Crotte]

Euh... Oui c'est clair...

Mais je ne comprends pas ton acharnement (sans vouloir te brusquer) à répondre à côté des questions ou problèmes exposés.

Je ne remet pas en cause ce que tu nous explique... je sais très bien qu'il n'y a aucune différence entre une vue et un select...

Ceci dit une procédure stockée permet de faire beaucoup plus de choses qu'une vue... et de ce point de vue là (sans jeux de mots... ), si le select s'avère tordu... il est plus performant de faire plusieurs "select" simples en remplissant des tables temporaires pour "in fine" selecter les tables temporaires en résultat de la procédure.

Encore une fois, je ne veux agacer personne, surtout pas SQLpro dont je connais la qualité en matière SQL. Je fais juste part de ce que j'ai pu constater lors de mon travail.