Il est très fréquent d’utiliser des vues pour simplifier la vie des personnes réalisant des requêtes, qu’il s’agisse de développeurs ou bien d’utilisateurs avancés qui réalisent des requêtes applicatives.

Mais beaucoup oublient que les vues sont, dans la plupart des cas, de simples alias, et que la requête exécutée par le moteur garde toute la charge due à la complexité de la définition des vues utilisées.

Tout d’abord, choisissons de définir une vue, et observons le comportement du moteur de données lorsqu’une requête consomme cette vue.

CREATE VIEW [HumanResources].[vEmployee]
AS
SELECT
    e.[BusinessEntityID]
    ,p.[Title]
    ,p.[FirstName]
    ,p.[MiddleName]
    ,p.[LastName]
    ,p.[Suffix]
    ,e.[JobTitle]
    ,pp.[PhoneNumber]
    ,pnt.[Name] AS [PhoneNumberType]
    ,ea.[EmailAddress]
    ,p.[EmailPromotion]
    ,a.[AddressLine1]
    ,a.[AddressLine2]
    ,a.[City]
    ,sp.[Name] AS [StateProvinceName]
    ,a.[PostalCode]
    ,cr.[Name] AS [CountryRegionName]
    ,p.[AdditionalContactInfo]
FROM [HumanResources].[Employee] e
	INNER JOIN [Person].[Person] p
	ON p.[BusinessEntityID] = e.[BusinessEntityID]
    INNER JOIN [Person].[BusinessEntityAddress] bea
    ON bea.[BusinessEntityID] = e.[BusinessEntityID]
    INNER JOIN [Person].[Address] a
    ON a.[AddressID] = bea.[AddressID]
    INNER JOIN [Person].[StateProvince] sp
    ON sp.[StateProvinceID] = a.[StateProvinceID]
    INNER JOIN [Person].[CountryRegion] cr
    ON cr.[CountryRegionCode] = sp.[CountryRegionCode]
    LEFT OUTER JOIN [Person].[PersonPhone] pp
    ON pp.BusinessEntityID = p.[BusinessEntityID]
    LEFT OUTER JOIN [Person].[PhoneNumberType] pnt
    ON pp.[PhoneNumberTypeID] = pnt.[PhoneNumberTypeID]
    LEFT OUTER JOIN [Person].[EmailAddress] ea
    ON p.[BusinessEntityID] = ea.[BusinessEntityID];

On peut constater que, malgré l’utilisation du nom de la vue (qui a donc simplifié le travail du développeur), le moteur remplace en arrière plan la vue par sa définition complète, d’où un plan d’exécution plus complexe qu’il n’aurait semblé au premier abord.

Mais à l’inverse, lorsque les colonnes sélectionnées et les prédicats de recherche n’ont pas à faire appel à certaines des tables définissant la vue, et bien le moteur simplifie la requête, en enlevant les tables inutiles.

D’une manière générale, les vues sont donc très pratiques pour simplifier et éclaircir le code T-SQL développé, mais peuvent être très pénalisantes au niveau des performances.

Voici par exemple un usage de la vue pour un besoin non justifié, là où le développeur aurait certainement dû privilégier une requête ne s’appuyant que sur les tables elles-mêmes.

A noter que, pour les éditions Entreprise de SQL Server, il est possible de définir des index clustered sur les vues (voir ici pour plus de détails), mais c’est une autre histoire…