Astuces SQL pour les développeurs

Depuis plus de dix ans, je m’intéresse principalement
aux interfaces d’accès aux données et mes conseils portent sur ce domaine
restreint. Pour bénéficier d’applications
fiables et performantes, il n’est pas inutile
de rappeler de temps à  autre les
recommandations suivantes à  bon
nombre de développeurs.

• Les administrateurs de base de données
  (DBA) ne doivent jamais communiquer
  le mot de passe sa. Par
  conséquent, ne leur demandez pas
  de vous le donner et n’essayez pas de
  le trouver écrit en toutes lettres sur
  un post-it collé sur l’écran du poste
  du DBA.

• Les DBA compétents verrouillent la
  base de données et ne donnent aucune
  permission d’accès aux tables
  de base. Par conséquent, vous devez
  demander au DBA de créer les tables
  et les procédures stockées permettant
  d’y accéder.

• Vous ne devez pas développer sous le
  compte sa une fois que vous avez le
  mot de passe, et n’utilisez en aucun
  cas un mot de passe vide, simplement
  parce que vous avez vu un « sa/no
  password » dans des exemples plus
  anciens.

• Ne créez pas vos requêtes à  la volée,
  ni avec l’opérateur et (&) ; cette ap
  proche ouvre la porte aux attaques
  par injection de code SQL. Créez des
  requêtes paramétrées, ou mieux encore, utilisez les procédures
  stockées écrites spécialement pour votre application.
  N’acceptez en aucune circonstance les valeurs d’utilisateurs
  ou d’autres sources non dignes de confiance. Un utilisateur
  n’a pas besoin d’être mal intentionné pour effectuer une
  saisie lourde de conséquences.

• Planifiez la création de procédures stockées pour l’exécution
  de toutes vos requêtes. Le DBA insistera peut-être
  d’emblée sur ce point, mais pour accroître les performances
  et renforcer sensiblement la sécurité, bâtissez
  votre structure autour de procédures stockées protégées
  bien ciblées. Les procédures stockées
  ciblées comportant un nombre
  limité de paramètres sont plus faciles
  à  compiler par SQL Server et lui permettent
  de créer des plans d’exécution
  efficaces applicables à  une
  grande diversité de valeurs de paramètres.

• Faites en sorte que le nombre de
  lignes retournées n’excède pas la capacité
  d’exploitation immédiate de
  l’utilisateur. Ne récupérez pas plus
  de colonnes que nécessaire et éviter
  les instructions SELECT *. Si vous
  spécifiez les noms de colonne, vous
  connaîtrez précisément celles renvoyées
  par SQL Server et leur ordre.
  Veillez à  ajouter des alias aux colonnes,
  afin de pouvoir utiliser plus facilement des
  contrôles liés leur attribuant des noms.

• Evitez les processus de mise à  jour côté client, si vous pouvez
  effectuer les mêmes tâches dans les procédures exécutées
  sur le serveur. Cette approche élimine les coûts associés
  aux échanges de données avec le client.

• N’utilisez pas ADO ou ADO.NET pour effectuer les opérations
  en bloc. Les interfaces d’accès aux données créent
  des programmes de copie en bloc désastreux. Essayez de
  voir comment utiliser les services de transformation de
  données (DTS) ou le programme de copie en bloc (BCP).
  L’utilisation de SQL-DMO pour piloter une opération de
  copie avec BCP aboutira à  de biens meilleures performances
  que n’importe quelle technique ADO séduisante
  de votre crue.

• Ne stockez pas des objets BLOB (binary large object) dans
  la base de données. Conservez dans celle-ci uniquement le
  chemin vers le BLOB et ses attributs, le type MIME et
  d’autres informatiques critiques (mais pas de texte ou
  d’images). Les opérations d’enregistrement et de récupération
  d’objets BLOB sont bien plus longues que l’enregistrement
  et la récupération des mêmes données à  partir
  d’un fichier. Par ailleurs, les BLOB vident le cache de données
  d’autres procédures et données utiles.

• Envisagez de définir le même délai d’attente pour les interfaces
  d’accès aux données (par ex., DB-Library, DAO,
  RDO, ODBC, OLE DB, ADO et ADO.NET). Vous ne pouvez
  pas résoudre les problèmes de performances en posant
  plus rapidement les questions. Trop souvent, les performances
  sont ralenties par la nature de la requête ou la manière
  dont SQL Server est programmé pour la traiter. Vous
  résoudrez plus de problèmes en utilisant des index appropriés
  qu’en choisissant un DataReader au lieu d’un Data-
  Adapter.