Ma journée :

Bonnes pratiques SQL

Benjamin — Wed, 17 Sep 2008 02:13:55 +0000

Voici une liste de quelques best practices pour la création de tables, d’instructions et de procédures stockées rédigée à partir de quelques articles glanés au fil du temps. Il s’agit davantage d’un aide mémoire que d’une liste d’éléments rigides à respecter ; il faut mettre en perspective plusieurs facteurs (fréquence d’utilisation de la requête, quantité de lignes de données à la source, jeu d’enregistrement retourné) lorsque l’on rédige des instructions SQL afin d’évaluer l’importance de respecter ces pratiques.

Conception de tables / tables temporaires :

Utiliser le plus petit type de données possible.
Si possible, préférer un type tinyint à un int et ainsi, préférer un int à un bigint. Il en va de même pour les colonnes de type texte, il est plus efficace de définir la longueur d’un champ char ou varchar selon le nombre de caractères du terme le plus long qu’elle contiendra.
Utiliser des clés primaires de type entier (int) ou de peu de caractères (ex. char(3)).
Éviter les types « float », « real » et « datetime » pour vos clés primaires.
Éviter le type « TEXT ».
Par souci de performance, si le champ doit contenir moins de 8000 caractères, utiliser le type VARCHAR.
Éviter les types « NCHAR » et « NVARCHAR » si non requis.
Ces types sont les équivalents Unicode des types CHAR et VARCHAR mais utilisent le double de l’espace utilisé par ces derniers (CHAR(1) = 1 byte ; NCHAR(1) = 2 bytes).
Choisir entre « CHAR » et « VARCHAR ».
Si la longueur des valeurs contenues dans le champ est assez constante, choisir le type CHAR ; si la longueur des valeurs varie beaucoup, choisir le type VARCHAR. L’espace utilisé par les valeurs contenues dans une colonne CHAR est constant et est le maximum autorisé par la colonne. Comme le type CHAR est de longueur fixe, le traitement de ce type de champ est plus rapide que les colonnes de type VARCHAR.
Définir un « CLUSTERED INDEX » sur chaque table.
Éviter l’utilisation de tables temporaires.
Il est préférable d’utiliser une variable de type table (stockée en mémoire) plutôt qu’une table temporaire (stockée dans la base de données temp sur le disque) lorsque le jeu d’enregistrement n’est pas trop gros.
Ne pas utiliser « SELECT INTO » pour créer une table temporaire.
Créez manuellement la table avec l’instruction CREATE TABLE. Le SELECT INTO verrouille la base de données temp ; ce qui peut amener les autres processus à subir des blocages.

Conception de requêtes :

Commentez votre code.
Les commentaires permettront aux autres programmeurs / développeurs et à vous-même de vous comprendre lorsque vous relirez votre code. Il n’y a aucune raison de ne pas inscrire de commentaires, ils n’affectent en rien le code SQL.
Inscrivez les mots clés SQL en lettres majuscules.
Afin d’améliorer la lisibilité de votre code.
Spécifier les colonnes dans les instructions « INSERT ».
Afin d’éviter les problèmes si la structure des tables constituant la requête change.
Ne pas utiliser « SELECT * ».
Spécifiez seulement les colonnes dont vous avez besoin. En plus de retourner des résultats inutiles l’utilisation d’un SELECT * peut empêcher l’utilisation d’un index couvrant.
Toujours utiliser une clause « WHERE ».
Afin de limiter le nombre d’enregistrements renvoyés et de retourner seulement les enregistrements nécessaires.
Éviter d’utiliser la clause « DISTINCT ».
Il est préférable d’utiliser une clause GROUP BY car elle est exécutée avant la clause DISTINCT dans le plan d’exécution d’une requête.
Éviter d’utiliser des curseurs.
Les curseurs utilisent énormément de ressources, il est préférable d’utiliser une approche ensembliste (set based) plutôt qu’une approche procédurale telle un curseur. Si un curseur est inévitable, préférer une boucle « WHILE ».
Éviter les « ORDER BY ».
Effectuer les tris (order by) au niveau du client ; si ce n’est pas possible, spécifier la colonne plutôt qu’utiliser son numéro.
Éviter les expressions suivantes qui ne sont pas sargable (qui ne profitent pas de l’utilisation d’un index et qui résultent en scan d’indexes ou de tables) :
1. L’utilisation du JOKER au début d’une expression dans une recherche WHERE [...] LIKE.
2. Les opérateurs « n’égale pas » (<> et NOT).
3. Les clauses IN et NOT IN, EXISTS et NOT EXISTS (bien que ces derniers soient préférables aux IN / NOT IN).
4. NOT LIKE
5. IS NULL
Utiliser des « Stored procedures ».
Dès qu’une application cliente doit exécuter des requêtes TSQL , il est préférable d’utiliser des procédures stockées (SPROC) plutôt que des scripts dans l’application. Voici quelques avantages :
1. Réduire le trafic sur le réseau.
2. Les plans d’exécution des SPROC peuvent être réutilisés par l’optimiseur de requêtes, ce qui aide à réduire la charge sur le serveur.
3. Permet d’encapsuler la logique d’affaire dans la base de données.
Débuter toutes les procédures stockées par « SET NOCOUNT ON ».
Cette commande permet de réduire le trafic sur le réseau et devrait débuter toutes les SPROC. Elle évite à SQL Server de calculer le nombre de lignes concernées par une requête ou une procédure stockée.
Ne pas préfixer les procédures stockées par « sp_ ».
Ce préfixe est réservé pour les procédures stockées systèmes. Lorsqu’une procédure débutant par « sp_ » est rencontrée, SQL essaie de la localiser premièrement dans la base de données master.
Éviter les longues requêtes.
Il est préférable de séparer les longues requêtes en plusieurs petites requêtes. Écrivez des requêtes claires et aussi courtes que possible.

Permissions :

Donner les permissions adéquates aux objets.
Ne pas donner des permissions aux usagers d’application dont ils n’ont pas besoin. Permettez seulement les opérations requises (SELECT, INSERT, DELETE, UPDATE, EXECUTE) par l’application sur les objets de la base de données. Dans le cas de tables contenant des données sensibles, spécifiez des permissions précises sur les colonnes plutôt que sur la table.
Ne jamais utiliser le login « SA » pour l’accès aux données pour une application!

Références :

SQL Server TSQL Coding Conventions, Best Practices, and Programming Guidelines
10+ tips for getting the best performance out of your SQL Server data types
SQL Server DBA Best Practices by Brad McGehe
Inside MS SQL Server : T-SQL Querying

Liens : Dynamics GP

Benjamin — Fri, 12 Sep 2008 00:29:56 +0000

J’ai ajouté une page où l’on peut retrouver des liens pointant vers différentes ressources concernant Dynamics GP : blogues, articles, sites divers.

N’hésitez pas à me faire part de sites à y ajouter!

Microsoft Powershell

Benjamin — Thu, 17 Jul 2008 23:59:54 +0000

En résumé : WOW!

Depuis quelques temps je vois de plus en plus d’articles ou de scripts destinés à Powershell, mais je ne m’y étais pas encore attardé : quelle erreur! Étant un amateur du terminal de linux et un irréductible du shell de Windows, Microsoft n’aurait pu me faire une plus belle surprise que cet outil.

Afin de démystifier un peu le sujet je vous suggère d’écouter le TechNet Webcast: An Overview of Windows PowerShell (Level 200) de Don Jones; en 40 minutes cela vous donnera une idée générale des possibilités de l’outil et vous donnera les bases pour l’explorer par vous-même.

Vous trouverez quelques applications “SQL” du Powershell en regardant les séries d’articles de “MAK” sur Databasejournal :

Microsoft Windows PowerShell and SQL Server 2005 SMO
Check your SQL Server using Windows PowerShell

Voici un script tiré de ses articles qui permet de lancer des backups sur un serveur SQL avec une simple ligne de commande dans le Powershell :

#backupSQL.ps1
param (
[string] $ServerName,
[string] $DatabaseName,
[string] $Backuptype ,
[string] $BackupPath
)
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
[System.IO.Directory]::CreateDirectory($BackupPath) | out-null
$srv=New-Object "Microsoft.SqlServer.Management.Smo.Server" "$servername"
$bck=new-object "Microsoft.SqlServer.Management.Smo.Backup"
if ($Backuptype -eq "FULL")
{
$bck.Action = ‘Database’
$extenstion=".BAK"
$text1="Full Backup "
}
if ($Backuptype -eq "TRAN")
{
$bck.Action = ‘Log’
$extenstion=".LOG"
$text1="Transactional Log Backup "
}
if ($Backuptype -eq "DIFF")
{
$bck.Incremental = 1
$extenstion=".DIFF"
$text1="Differential Backup "
}
$fil=new-object "Microsoft.SqlServer.Management.Smo.BackupDeviceItem"
$fil.DeviceType=‘File’
$fil.Name=[System.IO.Path]::Combine($BackupPath, $DatabaseName+ "_"+ [DateTime]::Today.ToString("yyyy_MM_dd")+$extenstion)
$bck.Devices.Add($fil)
$bck.Database=$DatabaseName
$bck.SqlBackup($srv)
write-host $text1 of $Databasename done

Une fois le script créé, il suffit de le lancer avec la commande

backupSQL "SQLSERVERNAME" "DATABASENAME" "FULL" "SAVEPATH"

Si vous désirez en apprendre plus voici quelques étapes pour commencer :

Téléchargez et installez l’application.
Tapez “powershell” dans Déarrer /exécuter.
Amusez-vous!

Fonction InitCap pour SQL Server

Benjamin — Tue, 15 Apr 2008 23:16:35 +0000

Pour ceux qui ne la connaissent pas, la fonction InitCap permet sous Oracle de remplacer la première lettre de chaque mot dans un string par une majuscule; les autres lettres sont en minuscule. Voici une fonction définie par l’usager pour simuler la fonction InitCap sous SQL Server.

J’utilise cette fonction depuis déjà longtemps au travail; je ne me souviens malheureusement pas à qui revient les mérites de la fonction originale…

CREATE FUNCTION [dbo].[initcap] (@TEXT VARCHAR(4000))
RETURNS VARCHAR(4000) AS BEGIN DECLARE @counter INT,
@length INT,
@CHAR CHAR(1),
@textnew VARCHAR(4000)
IF @TEXT <> ”
BEGIN
SET @TEXT = RTRIM(@TEXT)
SET @TEXT = LOWER(@TEXT)
SET @length = LEN(@TEXT)
SET @counter = 1
SET @TEXT = UPPER(LEFT(@TEXT, 1) ) + RIGHT(@TEXT, @length - 1)
WHILE @counter <> @length
BEGIN
SELECT @CHAR = SUBSTRING(@TEXT, @counter, 1)
IF @CHAR = SPACE(1) OR @CHAR = ‘_’ OR @CHAR = ‘,’ OR @CHAR = ‘.’ OR @CHAR = ‘\’
OR @char = ‘/‘ OR @char = ‘(‘ OR @char = ‘)‘ OR @char = ‘-‘
BEGIN
SET @textnew = LEFT(@text, @counter) + upper(substring(@text, @counter+1, 1)) + RIGHT(@text, (@length - @counter) - 1)
SET @text = @textnew
END
SET @counter = @counter + 1
END
END
RETURN @text END

Schémas de bases de données de MS Dynamics

Benjamin — Fri, 04 Apr 2008 22:20:22 +0000

Mise en situation :

Un utilisateur de Dynamics vient me voir pour m’apprendre que les relevés bancaires ont été conciliés par erreur… on ne sait pas quand, ni par qui. À l’aide de Log Explorer il a été facile de retrouver le moment où l’action a été produite; malheurusement il était impossible d’effectuer un rollback des transactions.

Résolution :

Passer un nombre d’heures indéterminé à reproduire les opérations effectuées par l’usager, «loguer» et scruter à la loupe toutes les entrées dans SQL Profiler et Log Explorer afin de déterminer tous les champs de toutes les tables qui ont pu être touchées afin d’effectuer les correctifs appropriées.

Souhait :

Pourquoi ne pourrais-je pas avoir les schémas des tables de la base de données… cela serait si facile.

Réponse divine :

Les diagrammes se trouvent sur le deuxième disque de l’installation de MS Dynamics GP. Il suffit d’installer la «bibliothèque d’outils de services professionnels».

À titre d’exemple, voici le schéma des tables du module des achats de GP :

Je regrette seulement de ne pas avoir trouvé ces schémas plus tôt…

Générer des numéros de ligne sous SQL Server 2000?

Benjamin — Fri, 28 Mar 2008 00:15:42 +0000

Sous SQL Server 2005, il est possible de facilement générer des numéros de ligne dans une requête en utilisant la fonction ROW_NUMBER.

On peut arriver au même résultat sous MSSQL2000 en utilisant un champ IDENTITY dans une table temporaire.

Un petit exemple qui dit tout :

SELECT NoEmploye, NomEmploye, IDENTITY(INT,1,1) AS [ROW Number]
INTO [#tempBen]
FROM Employes
ORDER BY DateEmbauche DESC