Principes de base des expressions de table, Partie 10 - Vues, ​​SELECT * et modifications DDL

Dans le cadre de la série sur les expressions de table, j'ai commencé le mois dernier la couverture des vues. Plus précisément, j'ai commencé la couverture des aspects logiques des vues et j'ai comparé leur conception avec celle des tables dérivées et des CTE. Ce mois-ci, je vais continuer la couverture des aspects logiques des vues, en concentrant mon attention sur les changements SELECT * et DDL.

Le code que j'utiliserai dans cet article peut être exécuté dans n'importe quelle base de données, mais dans mes démos, j'utiliserai TSQLV5, le même exemple de base de données que j'ai utilisé dans les articles précédents. Vous pouvez trouver le script qui crée et remplit TSQLV5 ici, et son diagramme ER ici.

Utiliser SELECT * dans la requête interne de la vue est une mauvaise idée

Dans la section conclusion de l'article du mois dernier, j'ai posé une question comme matière à réflexion. J'ai expliqué que plus tôt dans la série, j'avais plaidé en faveur de l'utilisation de SELECT * dans les expressions de table internes utilisées avec les tables dérivées et les CTE. Voir la partie 3 de la série pour plus de détails si vous avez besoin de vous rafraîchir la mémoire. Je vous ai ensuite demandé de réfléchir si la même recommandation serait toujours valable pour l'expression de table interne utilisée pour définir la vue. Peut-être que le titre de cette section était déjà un spoiler, mais je dirai tout de suite qu'avec les vues, c'est en fait une très mauvaise idée.

Je commencerai par les vues qui ne sont pas définies avec l'attribut SCHEMABINDING, qui empêche les modifications DDL pertinentes des objets dépendants, puis j'expliquerai comment les choses changent lorsque vous utilisez cet attribut.

Je vais passer directement à un exemple car ce sera la façon la plus simple de présenter mon argument.

Utilisez le code suivant pour créer une table appelée dbo.T1 et une vue appelée dbo.V1 basée sur une requête avec SELECT * sur la table :

UTILISER TSQLV5 ; SUPPRIMER LA VUE SI EXISTE dbo.V1 ; SUPPRIMER LA TABLE SI EXISTE dbo.T1 ; ALLER CRÉER UNE TABLE dbo.T1( keycol INT NOT NULL IDENTITY CONSTRAINT PK_T1 PRIMARY KEY, intcol INT NOT NULL, charcol VARCHAR(10) NOT NULL); INSERT INTO dbo.T1(intcol, charcol) VALUES (10, 'A'), (20, 'B');GO CREATE OR ALTER VIEW dbo.V1AS SELECT * FROM dbo.T1;GO

Observez que la table contient actuellement les colonnes keycol, intcol et charcol.

Utilisez le code suivant pour interroger la vue :

SELECT * FROM dbo.V1 ;

Vous obtenez le résultat suivant :

keycol intcol charcol----------- ----------- ----------1 10 A2 20 B

Rien de trop spécial ici.

Lorsque vous créez une vue, SQL Server enregistre les informations de métadonnées dans un certain nombre d'objets de catalogue. Il enregistre des informations générales, que vous pouvez interroger via sys.views, la définition de vue que vous pouvez interroger via sys.sql_modules, des informations de colonne que vous pouvez interroger via sys.columns, et plus d'informations sont disponibles via d'autres objets. Ce qui est également pertinent pour notre discussion, c'est que SQL Server vous permet de contrôler les autorisations d'accès par rapport aux vues. Ce dont je veux vous avertir lorsque vous utilisez SELECT * dans l'expression de table interne de la vue, c'est ce qui peut arriver lorsque des modifications DDL sont appliquées à des objets dépendants sous-jacents.

Utilisez le code suivant pour créer un utilisateur appelé user1 et accordez à l'utilisateur les autorisations nécessaires pour sélectionner les colonnes keycol et intcol dans la vue, mais pas charcol :

DROP USER IF EXISTS user1 ; CRÉER UN UTILISATEUR user1 SANS CONNEXION ; GRANT SELECT ON dbo.V1(keycol, intcol) TO user1 ;

À ce stade, examinons certaines des métadonnées enregistrées liées à notre vue. Utilisez le code suivant pour renvoyer l'entrée représentant la vue de sys.views :

SELECT SCHEMA_NAME(schema_id) AS schemaname, name, object_id, type_descFROM sys.viewsWHERE object_id =OBJECT_ID(N'dbo.V1');

Ce code génère la sortie suivante :

nom du schéma object_id type_desc----------- ----- ----------- ----------dbo V1 130099504 VIEW 

 Utilisez le code suivant pour obtenir la définition de la vue à partir de sys.modules :
 
SELECT définition FROM sys.sql_modulesWHERE object_id =OBJECT_ID(N'dbo.V1');
 

 Une autre option consiste à utiliser la fonction OBJECT_DEFINITION comme suit :
 
SELECT OBJECT_DEFINITION(OBJECT_ID(N'dbo.V1'));
 

 Vous obtenez le résultat suivant :
 
CREATE VIEW dbo.V1AS SELECT * FROM dbo.T1 ;
 

 Utilisez le code suivant pour interroger les définitions de colonne de la vue à partir de sys.columns :
 
SELECT name AS column_name, column_id, TYPE_NAME(system_type_id) AS data_typeFROM sys.columnsWHERE object_id =OBJECT_ID(N'dbo.V1');
 

 Comme prévu, vous obtenez des informations sur les trois colonnes de la vue keycol, intcol et charcol :
 
column_name column_id data_type----------- ----------- ----------keycol 1 intintcol 2 intcharcol 3 varchar
 

 Observez les ID de colonne (positions ordinales) associées aux colonnes.
 

 Vous pouvez obtenir des informations similaires en interrogeant la vue de schéma d'informations standard INFORMATION_SCHEMA.COLUMNS, comme suit :
 
SELECT COLUMN_NAME, ORDINAL_POSITION, DATA_TYPEFROM INFORMATION_SCHEMA.COLUMNSWHERE TABLE_SCHEMA =N'dbo' AND TABLE_NAME =N'V1' ;
 

 Pour obtenir les informations de dépendance de la vue (les objets auxquels elle fait référence), vous pouvez interroger sys.dm_sql_referenced_entities, comme suit :
 
SELECT OBJECT_NAME(referenced_id) AS referenced_object, referenced_minor_id, COL_NAME(referenced_id, referenced_minor_id) AS column_nameFROM sys.dm_sql_referenced_entities(N'dbo.V1', N'OBJECT');
 

 Vous trouverez la dépendance sur la table T1 et sur ses trois colonnes :
 
referenced_object referenced_minor_id nom_colonne------------------ ------------------- ------- ----T1 0 NULLT1 1 keycolT1 2 intcolT1 3 charcol
 

 Comme vous pouvez probablement le deviner, la valeur reference_minor_id pour les colonnes est l'ID de colonne que vous avez vu précédemment.
 

 Si vous souhaitez obtenir les autorisations de l'utilisateur1 sur V1, vous pouvez interroger sys.database_permissions, comme suit :
 
SELECT OBJECT_NAME(major_id) AS referenced_object, minor_id, COL_NAME(major_id, minor_id) AS column_name, permission_nameFROM sys.database_permissionsWHERE major_id =OBJECT_ID(N'dbo.V1') AND grantee_principal_id =USER_ID(N'user1'); 

 Ce code génère la sortie suivante, confirmant qu'effectivement l'utilisateur1 a des autorisations de sélection uniquement sur keycol et intcol, mais pas sur charcol :
 
referenced_object minor_id nom_colonne nom_permission------------------ ----------- ------------ -- --------------V1 1 keycol SELECTV1 2 intcol SELECT
 

 Encore une fois, la valeur minor_id est l'ID de colonne que vous avez vu précédemment. Notre utilisateur, user1, a des autorisations sur les colonnes dont les ID sont 1 et 2.
 

 Ensuite, exécutez le code suivant pour emprunter l'identité de user1 et essayer d'interroger toutes les colonnes de V1 :
 
EXECUTE AS USER =N'user1' ; SELECT * FROM dbo.V1;
 

 Comme vous vous en doutez, vous obtenez une erreur d'autorisation en raison de l'absence d'autorisation pour interroger charcol :
 Msg 230, Niveau 14, État 1, Ligne 141
La permission SELECT a été refusée sur la colonne 'charcol' de l'objet 'V1', base de données 'TSQLV5', schéma 'dbo'. 

 Essayez d'interroger uniquement keycol et intcol :
 
SELECT keycol, intcol FROM dbo.V1 ;
 

 Cette fois, la requête s'exécute avec succès, générant le résultat suivant :
 
keycol intcol----------- -----------1 102 20
 

 Pas de surprises jusqu'à présent.
 

 Exécutez le code suivant pour revenir à votre utilisateur d'origine :
 
REVERS;
 

 Appliquons maintenant quelques modifications structurelles à la table sous-jacente dbo.T1. Exécutez le code suivant pour ajouter d'abord deux colonnes appelées datecol et binarycol, puis pour supprimer la colonne intcol :
 
ALTER TABLE dbo.T1 ADD datecol DATE NOT NULL DEFAULT('99991231'), binarycol VARBINARY(3) NOT NULL DEFAULT(0x112233); ALTER TABLE dbo.T1 DROP COLUMN intcol;
 

 SQL Server n'a pas rejeté les modifications structurelles apportées aux colonnes référencées par la vue car la vue n'a pas été créée avec l'attribut SCHEMABINDING. Maintenant, pour la prise. À ce stade, SQL Server n'a pas encore actualisé les informations de métadonnées de la vue dans les différents objets du catalogue.
 

 Utilisez le code suivant pour interroger la vue, toujours avec votre utilisateur d'origine (pas encore user1) :
 
SELECT * FROM dbo.V1 ;
 

 Vous obtenez le résultat suivant :
 
keycol intcol charcol----------- ---------- ----------1 A 9999-12-312 B 9999-12-31 
 

 Notez que intcol renvoie en fait le contenu de charcol et que charcol renvoie le contenu de datecol. Rappelez-vous, il n'y a plus d'intcol dans la table mais il y a datecol. De plus, vous ne récupérez pas la nouvelle colonne binarycol. 
 

 Pour essayer de comprendre ce qui se passe, utilisez le code suivant pour interroger les métadonnées de colonne de la vue :
 
SELECT name AS column_name, column_id, TYPE_NAME(system_type_id) AS data_typeFROM sys.columnsWHERE object_id =OBJECT_ID(N'dbo.V1');
 

 Ce code génère la sortie suivante :
 
column_name column_id data_type----------- ----------- ----------keycol 1 intintcol 2 intcharcol 3 varchar
 

 Comme vous pouvez le constater, les métadonnées de la vue ne sont toujours pas actualisées. Vous pouvez voir intcol comme ID de colonne 2 et charcol comme ID de colonne 3. En pratique, intcol n'existe plus, charcol est censé être la colonne 2 et datecol est censé être la colonne 3.
 

 Vérifions s'il y a un changement avec les informations d'autorisation :
 
SELECT OBJECT_NAME(major_id) AS referenced_object, minor_id, COL_NAME(major_id, minor_id) AS column_name, permission_nameFROM sys.database_permissionsWHERE major_id =OBJECT_ID(N'dbo.V1') AND grantee_principal_id =USER_ID(N'user1'); 

 Vous obtenez le résultat suivant :
 
referenced_object minor_id nom_colonne nom_permission------------------ ----------- ------------ -- --------------V1 1 keycol SELECTV1 2 intcol SELECT
 

 Les informations sur les autorisations indiquent que l'utilisateur 1 dispose d'autorisations sur les colonnes 1 et 2 de la vue. Cependant, même si les métadonnées pensent que la colonne 2 s'appelle intcol, elle est en fait mappée sur charcol dans T1 dans la pratique. C'est dangereux car user1 n'est pas censé avoir accès à charcol. Et si dans la vraie vie cette colonne contenait des informations sensibles comme des mots de passe.
 

 Prenons à nouveau l'identité de user1 et interrogeons toutes les colonnes de la vue :
 
EXÉCUTER EN TANT QU'UTILISATEUR ='user1' ; SELECT * FROM dbo.V1;
 

 Vous obtenez une erreur d'autorisation indiquant que vous n'avez pas accès à charcol :
 Msg 230, Niveau 14, État 1, Ligne 211
La permission SELECT a été refusée sur la colonne 'charcol' de l'objet 'V1', base de données 'TSQLV5', schéma 'dbo'. 

 Cependant, voyez ce qui se passe lorsque vous demandez explicitement keycol et intcol :
 
SELECT keycol, intcol FROM dbo.V1 ;
 

 Vous obtenez le résultat suivant :
 
keycol intcol----------- ----------1 A2 B
 

 Cette requête réussit, seule elle renvoie le contenu de charcol sous intcol. Notre utilisateur, user1, n'est pas censé avoir accès à ces informations. Oups !
 

 À ce stade, revenez à l'utilisateur d'origine en exécutant le code suivant :
 
REVERS;
 
Actualiser le module SQL
 

 Vous pouvez clairement voir que l'utilisation de SELECT * dans l'expression de table interne de la vue est une mauvaise idée. Mais il n'y a pas que ça. En règle générale, il est judicieux d'actualiser les métadonnées de la vue après chaque modification DDL des objets et colonnes référencés. Vous pouvez le faire en utilisant sp_refreshview ou le sp_refreshmodule plus général, comme ceci :
 
EXEC sys.sp_refreshsqlmodule N'dbo.V1';
 

 Interrogez à nouveau la vue, maintenant que ses métadonnées ont été actualisées :
 
SELECT * FROM dbo.V1 ;
 

 Cette fois, vous obtenez le résultat attendu :
 
keycol charcol datecol binarycol----------- ---------- ---------- ---------1 A 9999 -12-31 0x1122332 B 9999-12-31 0x112233
 

 La colonne charcol est nommée correctement et affiche les données correctes ; vous ne voyez pas intcol, mais vous voyez les nouvelles colonnes datecol et binarycol.
 

 Interrogez les métadonnées de la colonne de la vue :
 
SELECT name AS column_name, column_id, TYPE_NAME(system_type_id) AS data_typeFROM sys.columnsWHERE object_id =OBJECT_ID(N'dbo.V1');
 

 La sortie affiche désormais les informations de métadonnées de colonne correctes :
 
column_name column_id data_type----------- ----------- ----------keycol 1 intcharcol 2 varchardatecol 3 datebinarycol 4 varbinary 

 Interroger les autorisations de l'utilisateur 1 sur la vue :
 
SELECT OBJECT_NAME(major_id) AS referenced_object, minor_id, COL_NAME(major_id, minor_id) AS column_name, permission_nameFROM sys.database_permissionsWHERE major_id =OBJECT_ID(N'dbo.V1') AND grantee_principal_id =USER_ID(N'user1'); 

 Vous obtenez le résultat suivant :
 
referenced_object minor_id nom_colonne nom_permission------------------ ----------- ------------ -- --------------V1 1 keycol SELECT
 

 Les informations d'autorisation sont maintenant correctes. Notre utilisateur, user1, n'est autorisé qu'à sélectionner keycol, et les informations d'autorisation pour intcol ont été supprimées.
 

 Pour être sûr que tout va bien, testons cela en usurpant l'identité de user1 et en interrogeant la vue :
 
EXÉCUTER EN TANT QU'UTILISATEUR ='user1' ; SELECT * FROM dbo.V1;
 

 Vous obtenez deux erreurs d'autorisation en raison du manque d'autorisations contre datecol et binarycol :
 Msg 230, Niveau 14, État 1, Ligne 281
La permission SELECT a été refusée sur la colonne 'datecol' de l'objet 'V1', base de données 'TSQLV5', schéma 'dbo'.
 

 Msg 230, Niveau 14, État 1, Ligne 281
La permission SELECT a été refusée sur la colonne 'binarycol' de l'objet 'V1', base de données 'TSQLV5', schéma 'dbo'.
 

 Essayez d'interroger keycol et intcol :
 
SELECT keycol, intcol FROM dbo.V1 ;
 

 Cette fois, l'erreur indique correctement qu'il n'y a pas de colonne appelée intcol :
 Msg 207, niveau 16, état 1, ligne 279 

 Nom de colonne 'intcol' non valide.
 

 Interroger uniquement intcol :
 
SELECT keycol FROM dbo.V1 ;
 

 Cette requête s'exécute avec succès, générant le résultat suivant :
 
keycol-----------12
 

 À ce stade, revenez à votre utilisateur d'origine en exécutant le code suivant :
 
REVERS;
 
Suffit-il d'éviter SELECT * et d'utiliser des noms de colonnes explicites ?
 

 Si vous suivez une pratique qui dit pas de SELECT * dans l'expression de la table interne de la vue, cela suffira-t-il à vous éviter des ennuis ? Eh bien, voyons…
 

 Utilisez le code suivant pour recréer la table et la vue, mais cette fois-ci, répertoriez explicitement les colonnes dans la requête interne de la vue :
 
DOP VIEW IF EXISTS dbo.V1;DOP TABLE IF EXISTS dbo.T1;GO CREATE TABLE dbo.T1( keycol INT NOT NULL IDENTITY CONSTRAINT PK_T1 PRIMARY KEY, intcol INT NOT NULL, charcol VARCHAR(10) NOT NULL); INSERT INTO dbo.T1(intcol, charcol) VALUES (10, 'A'), (20, 'B');GO CREATE OR ALTER VIEW dbo.V1AS SELECT keycol, intcol, charcol FROM dbo.T1;GO
 

 Interroger la vue :
 
SELECT * FROM dbo.V1 ;
 

 Vous obtenez le résultat suivant :
 
keycol intcol charcol----------- ----------- ----------1 10 A2 20 B
 

 Encore une fois, accordez à user1 les autorisations pour sélectionner keycol et intcol :
 
GRANT SELECT ON dbo.V1(keycol, intcol) TO user1 ;
 

 Ensuite, appliquez les mêmes modifications structurelles que précédemment :
 
ALTER TABLE dbo.T1 ADD datecol DATE NOT NULL DEFAULT('99991231'), binarycol VARBINARY(3) NOT NULL DEFAULT(0x112233); ALTER TABLE dbo.T1 DROP COLUMN intcol;
 

 Notez que SQL Server a accepté ces modifications, même si la vue a une référence explicite à intcol. Encore une fois, c'est parce que la vue a été créée sans l'option SCHEMABINDING.
 

 Interroger la vue :
 
SELECT * FROM dbo.V1 ;
 

 À ce stade, SQL Server génère l'erreur suivante :
 Msg 207, Niveau 16, État 1, Procédure V1, Ligne 5 [Batch Start Line 344]
Nom de colonne 'intcol' non valide.
 

 Msg 4413, Niveau 16, État 1, Ligne 345
Impossible d'utiliser la vue ou la fonction 'dbo.V1' en raison d'erreurs de liaison.
 

 SQL Server a tenté de résoudre la référence intcol dans la vue, et bien sûr sans succès.
 

 Mais que se passe-t-il si votre plan initial était de supprimer intcol et de le rajouter plus tard ? Utilisez le code suivant pour le rajouter, puis interrogez la vue :
 
ALTER TABLE dbo.T1 ADD intcol INT NOT NULL DEFAULT(0); SELECT * FROM dbo.V1;
 

 Ce code génère la sortie suivante :
 
keycol intcol charcol----------- ----------- ----------1 0 A2 0 B
 

 Le résultat semble correct.
 

 Que diriez-vous d'interroger la vue en tant qu'utilisateur 1 ? Essayons :
 
EXECUTE AS USER ='user1';SELECT * FROM dbo.V1;
 

 Lors de l'interrogation de toutes les colonnes, vous obtenez l'erreur attendue en raison du manque d'autorisations contre charcol :
 Msg 230, Niveau 14, État 1, Ligne 367
La permission SELECT a été refusée sur la colonne 'charcol' de l'objet 'V1', base de données 'TSQLV5', schéma 'dbo'. 

 Interrogez explicitement keycol et intcol :
 
SELECT keycol, intcol FROM dbo.V1 ;
 

 Vous obtenez le résultat suivant :
 
keycol intcol----------- -----------1 02 0
 

 Il semble que tout soit en ordre grâce au fait que vous n'avez pas utilisé SELECT * dans la requête interne de la vue, même si vous n'avez pas actualisé les métadonnées de la vue. Néanmoins, il peut être judicieux d'actualiser les métadonnées de la vue après les modifications DDL apportées aux objets et colonnes référencés pour plus de sécurité.
 

 À ce stade, revenez à votre utilisateur d'origine en exécutant le code suivant :
 
REVERS;
 
CONNEXION AU SCHÉMA
 

 En utilisant l'attribut de vue SCHEMABINDING, vous pouvez vous épargner beaucoup des problèmes susmentionnés. L'une des clés pour éviter le problème que vous avez vu précédemment est de ne pas utiliser SELECT * dans la requête interne de la vue. Mais il y a aussi le problème des changements structurels par rapport aux objets dépendants, comme la suppression de colonnes référencées, qui peuvent toujours entraîner des erreurs lors de l'interrogation de la vue. En utilisant l'attribut de vue SCHEMABINDING, vous ne serez pas autorisé à utiliser SELECT * dans la requête interne. De plus, SQL Server rejettera les tentatives d'application des modifications DDL pertinentes aux objets et colonnes dépendants. Par pertinent, je veux dire des changements comme la suppression d'une table ou d'une colonne référencée. L'ajout d'une colonne à une table référencée n'est évidemment pas un problème, donc SCHEMABINDING n'empêche pas un tel changement.
 

 Pour illustrer cela, utilisez le code suivant pour recréer la table et la vue, avec SCHEMABINDING dans la définition de la vue :
 
DOP VIEW IF EXISTS dbo.V1;DOP TABLE IF EXISTS dbo.T1;GO CREATE TABLE dbo.T1( keycol INT NOT NULL IDENTITY CONSTRAINT PK_T1 PRIMARY KEY, intcol INT NOT NULL, charcol VARCHAR(10) NOT NULL); INSERT INTO dbo.T1(intcol, charcol) VALUES (10, 'A'), (20, 'B');GO CREATE OR ALTER VIEW dbo.V1 WITH SCHEMABINDINGAS SELECT * FROM dbo.T1;GO
 

 Vous obtenez une erreur :
 Msg 1054, Niveau 15, État 6, Procédure V1, Ligne 5 [Batch Start Line 387]
La syntaxe '*' n'est pas autorisée dans les objets liés au schéma. 

 Lorsque vous utilisez SCHEMABINDING, vous n'êtes pas autorisé à utiliser SELECT * dans l'expression de table interne de la vue.
 

 Essayez de recréer la vue, mais cette fois avec une liste de colonnes explicite :
 
CRÉER OU MODIFIER LA VUE dbo.V1 AVEC SCHEMABINDINGAS SELECT keycol, intcol, charcol FROM dbo.T1;GO
 

 Cette fois, la vue est créée avec succès.
 

 Accordez à user1 les autorisations sur keycol et intcol :
 
GRANT SELECT ON dbo.V1(keycol, intcol) TO user1 ;
 

 Ensuite, essayez d'appliquer des modifications structurelles à la table. Commencez par ajouter quelques colonnes :
 
ALTER TABLE dbo.T1 ADD datecol DATE NOT NULL DEFAULT('99991231'), binarycol VARBINARY(3) NOT NULL DEFAULT(0x112233);
 

 L'ajout de colonnes n'est pas un problème car elles ne peuvent pas faire partie des vues existantes liées au schéma, donc ce code se termine avec succès.
 

 Essayez de supprimer la colonne intcol :
 
ALTER TABLE dbo.T1 DROP COLUMN intcol ;
 

 Vous obtenez l'erreur suivante :
 Msg 5074, Niveau 16, État 1, Ligne 418
L'objet 'V1' dépend de la colonne 'intcol'.
 

 Msg 4922, niveau 16, état 9, ligne 418
ALTER TABLE DROP COLUMN intcol a échoué car un ou plusieurs objets accèdent à cette colonne.
 

 La suppression ou la modification de colonnes référencées n'est pas autorisée lorsqu'il existe des objets liés au schéma.
 

 Si vous devez toujours supprimer intcol, vous devrez d'abord supprimer la vue de référencement liée au schéma, appliquer la modification, puis recréer la vue et réaffecter les autorisations, comme suit :
 
DROP VIEW IF EXISTS dbo.V1;GO ALTER TABLE dbo.T1 DROP COLUMN intcol;GO CREATE OR ALTER VIEW dbo.V1 WITH SCHEMABINDINGAS SELECT keycol, charcol, datecol, binarycol FROM dbo.T1;GO GRANT SELECT ON dbo. V1(keycol, datecol, binarycol) TO user1;GO
 

 Bien sûr, à ce stade, il n'est pas nécessaire d'actualiser la définition de la vue, car vous l'avez créée à nouveau.
 

 Maintenant que vous avez terminé les tests, exécutez le code suivant pour le nettoyage :
 
SUPPRIMER LA VUE SI EXISTE dbo.V1 ;SUPPRIMER LA TABLE SI EXISTE dbo.T1 ;SUPPRIMER L'UTILISATEUR SI EXISTE user1 ;
 
Résumé
 

 Utiliser SELECT * dans l'expression de table interne de la vue est une très mauvaise idée. Une fois les modifications structurelles appliquées aux objets référencés, vous pouvez obtenir des noms de colonne incorrects et même permettre aux utilisateurs d'accéder à des données auxquelles ils ne sont pas censés avoir accès. Il est important de répertorier explicitement les noms de colonne référencés.
 

 En utilisant SCHEMABINDING dans la définition de la vue, vous êtes obligé de répertorier explicitement les noms de colonne, et les modifications structurelles pertinentes apportées aux objets dépendants sont rejetées par SQL Server. Par conséquent, il peut sembler que la création de vues avec SCHEMBINDING est toujours une bonne idée. Cependant, il y a une mise en garde avec cette option. Comme vous l'avez vu, appliquer des modifications structurelles aux objets référencés lorsque SCHEMBINDING est utilisé devient un processus plus long et plus élaboré. Cela peut particulièrement être un problème dans les systèmes qui doivent avoir une très haute disponibilité. Imaginez que vous deviez remplacer une colonne définie par VARCHAR(50) par VARCHAR(60). Ce n'est pas une modification autorisée s'il existe une vue définie avec SCHEMABINDING faisant référence à cette colonne. Les implications de la suppression d'un tas de vues de référence, qui pourraient être référencées par d'autres vues, etc., pourraient être problématiques pour le système. En bref, il n'est pas toujours si trivial pour les entreprises d'adopter simplement une politique qui stipule que SCHEMABINDING doit être utilisé dans tous les objets qui le prennent en charge. Cependant, adopter une politique pour ne pas utiliser SELECT * dans les requêtes internes des vues devrait être plus simple. 
 

 Il y a beaucoup plus à explorer concernant les vues. A suivre le mois prochain…