Les vues sont vraiment très populaire dans beaucoup de companies pour les raisons suivantes:
- Les données sont publiées via une View sur laquelle on applique la sécurité. Un access direct aux data model n'est jamais fournit.
- Les données sont modifiés à l'aide de stored proc (utilisation de sécurité EXECUTE).
- Dans ce cas de figure, la view intervient comme une couche d'abstration masquant le Data Model sous-jacent. Il est dont possible de faire évoluer le schéma sans que cela perturbe les applications clientes en adaptant les views.
- Permet d'organiser les données pour export (bien qu'il y ait d'autres outils pour cela).
- Permet de nommer clairement (humainement compréhensible) les colonnes.
- Permet de masquer les informations non pertinentes.
- Par défaut, les enregistrements d'une view peuvent être mis-à-jour ou effacés (si la view n'est, bien entendu, pas trop compliqué. Voir 7-10).
- Il faut garder à l'esprit que les views diminuent les performances du moteur DB (parce que les noms sont évalués on-the-fly). Ainsi, on veillera à ne jamais dépasser 5 niveaux (View built on another view).
- Eviter les jointures dans le views (après 5 jointures, les performances sont terriblement mauvaises).
SCHEMABINDING
Les views n'utilisent pas de contrainte fortes sur le schema (Par default, SCHEMABINDING n'est pas actif). Cela présent un avantage et un inconvénient.L'avantage est qu'il est possible de modifier le schéma sous-jacent sans devoir effacer et recréer la view. C'est vraiment pratique pour les opérations de maintenance. Cependant, si erreur il y a (parce qu'il manque une colonne nécessaire dans la table sous-jacente), elle ne sera révélée que lorsque la view sera accédée.
Avec un SCHEMABINDING, il sera impossible de modifier les tables sous-jacentes sans détruire les views qui l'utilise (pour les recréer après).
Cela diminue certe le risque d'erreur mais rends la maintenance très contraignante.
Persistant Index
Comme précisé précédemment, les Views ne sont pas très performantes. C'est encore plus vrai si elles couvrent de grandes tables ou de multiple jointure.L'une des façon de contourner ces problèmes de performances est d'utiliser une "persistant index" sur la view.
Cette opération d'indexation de view crée effectivement un CLUISTERED INDEX. C'est a dire un index B-TREE contenant les pages de données... comme il s'agit d'une vuew, c'est une copie des pages de donnée qui se retrouvent dans l'arbre.
Et bien entendu, ce sont toutes les données qui sont dupliquée. La view sera effectivement performante... mais il y a un prix (les données sont dupliquées).
Bien que couteuse, cette métode a un avantage indéniable. En cas de corruption de la table source, SQL Server sera capable de récupérer les données corrompues depuis le "persistant index" (avec DBCC DBRepair).
Maintenance: Utilisation de view et Triggers
Si une table disparait du data-model pour être remplacé par une structure plus compliquée, il est possible de la "re-rendre disponible" via une View.
L'utilisation de TRIGGER INSTEAD OF permet même de continuer à supporter les operations insert/Update/Delete sur la view.
Stored Procedure
Pas grand chose de nouveau à apprendre dans ce domaine. Cependant, ce ne fût pas une perte de temps.
Il est fortement conseillé d'éviter l'usage des tables temporaires (#TempTableName) et des Curseurs lorsque cela est possible. L'utilisation de nouvelles structures et fonctionnalités de SQL Server permettent d'obtenir des codes 30 fois plus rapides.
Il ne faut JAMAIS utiliser le préfix "sp_" pour nommer les procédure. "sp_" est réservé aux "System Procedures". Lorsque l'interpreteur SQL essaye de résourde le nom de la stored proc commençant par "sp_" dans la master DB. Si elle n'y est pas retrouvée, une tentative de localisation dans la DB courante est alors entamée. Cela représente une surcharge d'exécution inutile!
Une stored procedure retourne toujours un entier. Cette fonctionnalité devrait être utilisée pour retourné un status d'éxécution à l'appellant. Par convention 0 = false, 1..N indique un status.
Le status est assigné avec avec l'instruction return (ex: RETURN 2).
Le status est récupèré lors de l'appel par une assignation directe.
Exemple:
DECLARE @UspStatus integer
DECLARE @AParam varchar(50)
SELECT @AParam = 'Hello'
DECLARE @MyResultingText varchar(100)
EXEC @UpsStatus = MyStoredProc "Param1", 5, @AParam, @MyResultingText OUTPUT
Recommandations
- Préfixer les stored procedure avec "usp_" pour "User Stored Procedure" (recommandation).
- Lors des appels de stored procedure, ne pas oublier d'utiliser le mot clé OUTPUT pour récupérer un paramètre par valeur (sinon NULL est retourné).
EXECUTE @ProcStatus = ProcedureName ParameterValue, @ParameterVariable, @ReturnedValue OUTPUT - Une stored procédure doit toujours vérifier la validité de sess paramètres.
IF (@Value <0 )
RAISERROR( 'Error Message', 14, 1 )
RETURN
END - Lors d'un RAISERROR, ne pas utiliser des erreurs avec une trop grande sévérité car cela rompt la connection (avec des effets indésirés).
- Utiliser la variable @@recordCount pour connaître le nombre de records retourné par la dernière opération SQL.
- Lors de la modification d'une stored procédure, ajouter les nouveaux parametres avec une assignation de valeur par défaut. Cela permet aux applications existantes de continuer à fonctionner sans modification.
- Lors de l'appel d'une stored procédure, utiliser le mot clé DEFAULT pour utiliser la valeur par défaut (signalée dans la définition dans la store procédure).
Le plan d'exécution permet d'avoir une synthèse des opérations effectuées par SQL Server durant l'exécution d'une requête SQL.
L'activation de l'EXECUTION PLAN depuis la console SQL est triviale (depuis la barre des boutons).
Cependant, lorsqu'il s'agit d'une stored procedure, il faut faire appel à des options spécifiques.
Il est ainsi possible de détecter les opérations couteuses dans une stored procedure afin de les optimiser.
Il y a différentes façons d'obtenir des informations d'exécution:
SET STATISTIC IO ON/OFF
Affiche dans les messages le nombre de pages de 8kb lues depuis le disque.
Logical Reads: # de pages qui devaient lues pour atteindre l'objectif.
Physical Reads: # de pages chargées depuis le disque (les autres pages se trouvaient dans le cache).
Read-Aheads: Lors d'operations avec temps de processing perdu, SQL serveur prend l'initiative de lire des pages complémentaires (# de pages chargées en plus dans le cache).
SET STATISTIC TIME ON/OFF
Affiche les details de temps d'exécution dans les messages. SET STATISTICS PROFILE ON
Fonctionnalité très utile mais malheureusement disparue en SQL2008.
Fournit le plan d'exécution sous forme de table relationnelle.
Il y est possible de lire l'entièreté du schema d'execution presqu'aussi simplement que le graphique lui-même.
SET STATISTICS XML ON
Produit les même information que STATISTICS PROFILE au format XML.
Ce format à l'inconvenient d'être moins lisible et donc plus difficile à exploité par simple lecture. Cependant, il existe une foule de logiciel exploitant ce format pour en reconstituer un graphique.
Contient en autre un noeud nommé MissingIndexGroup.
Aucun commentaire:
Enregistrer un commentaire