Performances de VIEW par rapport à une instruction SQL
J'ai une question qui va quelque chose comme ce qui suit:
select <field list>
from <table list>
where <join conditions>
and <condition list>
and PrimaryKey in (select PrimaryKey from <table list>
where <join list>
and <condition list>)
and PrimaryKey not in (select PrimaryKey from <table list>
where <join list>
and <condition list>)
Les sous-requêtes de sélection à la fois disposer de plusieurs sous-requêtes select de leur propre que je ne suis pas montrant afin de ne pas encombrer la déclaration.
L'un des développeurs sur mon équipe pense que d'un point de vue serait mieux. Je suis en désaccord dans l'instruction SQL utilise des variables passées par le programme (basé sur l'utilisateur, Id de connexion).
Existe-il des règles strictes et rapides sur le moment où une vue doit être utilisée au lieu d'utiliser une instruction SQL? Ce type de gain de performance sont les questions en cours d'exécution des instructions SQL sur leur propre contre les tables régulières vs contre les points de vue. (Notez que toutes les jointures /où les conditions sont contre les colonnes indexées, de sorte que ne devrait pas être un problème.)
MODIFIER pour la précision...
Voici la requête que je travaille avec:
select obj_id
from object
where obj_id in(
(select distinct(sec_id)
from security
where sec_type_id = 494
and (
(sec_usergroup_id = 3278
and sec_usergroup_type_id = 230)
or
(sec_usergroup_id in (select ug_gi_id
from user_group
where ug_ui_id = 3278)
and sec_usergroup_type_id = 231)
)
and sec_obj_id in (
select obj_id from object
where obj_ot_id in (select of_ot_id
from obj_form
left outer join obj_type
on ot_id = of_ot_id
where ot_app_id = 87
and of_id in (select sec_obj_id
from security
where sec_type_id = 493
and (
(sec_usergroup_id = 3278
and sec_usergroup_type_id = 230)
or
(sec_usergroup_id in (select ug_gi_id
from user_group
where ug_ui_id = 3278)
and sec_usergroup_type_id = 231)
)
)
and of_usage_type_id = 131
)
)
)
)
or
(obj_ot_id in (select of_ot_id
from obj_form
left outer join obj_type
on ot_id = of_ot_id
where ot_app_id = 87
and of_id in (select sec_obj_id
from security
where sec_type_id = 493
and (
(sec_usergroup_id = 3278
and sec_usergroup_type_id = 230)
or
(sec_usergroup_id in (select ug_gi_id
from user_group
where ug_ui_id = 3278)
and sec_usergroup_type_id = 231)
)
)
and of_usage_type_id = 131
)
and
obj_id not in (select sec_obj_id
from security
where sec_type_id = 494)
)
source d'informationauteur Matt W.
Vous devez vous connecter pour publier un commentaire.
Selon le fournisseur de base de données, en général, l'exécution d'une requête sur une vue combine le SQL définis dans la Vue avec la clause where de prédicats et de la clause Order By expressions de tri annexé à la sql que vous passez par rapport à la Vue, à venir avec un combiné complet de la requête SQL à exécuter. C'est alors exécutée comme si elle avait elle-même été adoptée à la requête processsor, il devrait donc y avoir aucune différence.
Points de vue sont un outil d'organisation, pas une amélioration des performances de l'outil.
De SQL Server en Vue de la résolution
Régulière (non index /matérialisés) les Vues sont des alias; ils n'offrent pas les avantages de performance. La sélection d'une Vue génère exactement le même plan de requête que de sélectionner directement à partir de la table.
Vues de côté, ne sont pas les clés primaires ET les clauses redondantes? Si la valeur PrimaryKey est DANS une liste, ne serait-il pas de ne pas être DANS l'autre liste? Je pense que la condensation de ces deux clauses dans l'une serait de booster les performances.