> Data > Astuces SQL pour les développeurs

Astuces SQL pour les développeurs

Data - Par iTPro.fr - Publié le 24 juin 2010
email

Mis en ligne le 11/05/2005 - Publié en Juin 2004

Le plein de conseils...
 

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.

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

Data - Par iTPro.fr - Publié le 24 juin 2010