Lorsqu’une application doit exécuter une requête dans une base de données, il est préférable que celle-ci appelle une procédure stockée plutôt que d’envoyer une commande T-SQL construite dans le code de l’application.
Outre l’avantage de sécurité contre les attaques par injection et la maintenabilité du code, voici les autres avantages que cela procure :
Archives pour la catégorie Moteur de base de données SQL Server
Les posters des tables système de SQL Server
Voici 3 liens vers les posters qui présentent les relations entre les objets système de SQL Server 2000 à 2008 …
Options de démarrage du service SQL Server
Il existe plusieurs commutateurs qui permettent de paramétrer le démarrage du service SQL Server.
Comment y accéder ? Quels sont-ils ? Quelles valeurs doivent-ils prendre ?
Lire la suite
[Agent SQL Server] Gestion de l’historique
Outre sa principale fonctionnalité de gestion d’exécutions, l’Agent SQL Server comporte quelques fonctionnalités intéressantes concernant la gestion de son historique.
Lire la suite
Ecriture ensembliste de triggers
Lors de mes participations au forum SQL Server de ce site, j’ai plusieurs fois vu des participants montrer leur trigger, qui spécifie du code non ensembliste, c’est-à -dire :
– Un traitement ligne à ligne, avec une boucle WHILE, ou un curseur,
– Une affectation de variables par sélection des tables virtuelles INSERTED et DELETED.
Dans le premier cas, il faut savoir que les SGBDR modernes sont conçus pour traiter des ensembles de données, et non pas pour traiter des lignes une par une, à la façon d’un curseur. Rappelons que les curseurs datent de COBOL (si vous vous rappelez des fichiers séquentiels indexés et de la rigidité de ce langage, cela doit vous dégoûter d’en écrire).
Par conséquent, tout traitement qui n’est pas ensembliste sera forcément plus long que celui qui l’est.
Dans le second cas, c’est en fait la première ligne mise à jour qui subira le traitement du trigger, parce qu’une variable ne peut être affectée au plus que par une seule valeur. Lire la suite
Purge du cache de plans
Il est possible qu’un jour vous trouviez dans les journaux de SQL Server le libellé suivant :
SQL Server has encountered n occurrence(s) of cachestore flush for the (partie du cache de plans) cachestore due to some database maintenance or reconfigure operations »
Ce message n’apparaît qu’à partir du SP2 de SQL Server 2005, et il est écrit par intervalles de 5 minutes.
La purge du cache de plans peut se produire dans les cas suivants :
Lire la suite
Recherche d’indexes manquants sous SQL Server 2005
Une nouvelle fonctionnalité intéressante, introduite avec SQL Server 2005, est la recherche d’indexes manquants.
Elle permet, de façon très simple, de trouver les indexes manquants qui pourraient simplifier le travail
du moteur de base de données s’ils étaient posés sur des tables de base ou des vues indexées.
Néanmoins, cette fonctionnalité comporte quelques limitations, qui doivent être prise en compte avant qu’on
ait décidé de créer l’index conseillé par SQL Server.
Comme vous le verrez, plusieurs sujets sont connexes à cet article, mais nous ne les aborderons pas ici.
Ils seront l’objet de prochains articles.