IF(NOT @yard_id IS NULL)
BEGIN
SELECT * FROM Yards WHERE yard_id = @yard_id AND year = @year;
END
ELSE
BEGIN
SELECT * FROM Yards WHERE year = @year;
END

Cette situation arrive, entre autres, lorsque nous avons un paramètre “optionnel” et que nous voulons qu’il n’influence pas le résultat lorsqu’il est absent.

Une autre version de cette même requête serait alors

SELECT * FROM Yards
WHERE yard_id = COALESCE(@yard_id, dbo.YardReport.yard_id)
AND year = @year;

où COALESCE, qui semble être la traduction de FUSIONNER, fait en sorte de retourner le premier paramètre non nul de ses arguments. Dans notre situation, si @yard_id est nul, COALESCE vas retourner la valeur de la ligne en cours, ce qui est toujours vrai.

Parmis les avantages de cette utilisation, les plus intéressantes sont la maintenance du code et la lisibilité. Effectivement, dans des requêtes plus complexes, la deuxième représentation sera beaucoup plus facile à maintenir.

Bonne pratique

Voici la requête en question:

UPDATE Table_1
SET Champ_1 = Champ_1 + 1
WHERE Id = 123;

où le Champ_1 est un champ numérique permettant les “null”. Lors de l’exécution de cette requête, même si la ligne 123 existait dans la DB la mise à jour du Champ_1 ne s’effectuait pas et phpMyAdmin donnait 0 ligne modifiée.

Que ce passe-t-il ?

Tout ici ce joue autour du champ numérique qui supports les “null”. Le fait que le Champ_1 support le nul et qu’il a la valeur nulle fait en sorte que l’ajout de 1 à “null” donne “null” et fait en sorte que la ligne “n’est pas mise à jour”.

happy programming

Par exemple, en .NET (C#) on pourrait utiliser la commande suivante pour inverser un booléen:

myVar = false;
myVar = !myVar;

Pour SQL Server nous devons utiliser l’opérateur binaire XOR (^) :

declare @var_bit bit;
print ‘Set à 0′
set @var_bit = 0;
print @var_bit
set @var_bit = @var_bit ^ 1
print @var_bit
print ‘Set à 1′
set @var_bit = 1;
print @var_bit
set @var_bit = @var_bit ^ 1
print @var_bit

Résultat:

Set à 0
0
1
Set à 1
1
0

Voilà…

Les tables

Que les tables que nous créons respectent les formes normales ou non, elles doivent avoir un nom qui est significatif pour le contenu qu’elles représentent.

Règle générale, je nomme les tables avec un “s” à la fin pour indiqué que la table contient plusieurs éléments ce qui est à première vu évident. Cependant, dans un environnement de groupe avoir un standard pour la création des noms de table aide à la rapidité du développement et à la lecture.

Par exemple, la table événement s’écrirait ”evenements”.

En règle général, les tables dites de jointure se composent des noms des autres tables qu’elle fait la jointure.

Par exemple, la table “activites” à une table de jointure avec “evenements” qui se nomme “evenementActivites”.

Dans ce dernier exemple, on peut comprendre qu’un événement à plusieurs Activités.

Les colonnes > La colonne identité

Comment choisir la taille de notre colonne identité que l’on définit avec un chiffre “auto-increment” ? Est-ce que l’on choisi BigInt (2^63), Int (2 147 483 648 = 2^31), SmallInt (32 768 = 2^15), TinyInt (256 = 2^8 valeurs) ?

Pour nous aider dans notre choix, nous devons analyser et estimer la quantité d’enregistrement qui sera créé dans cette table.

Par exemple, si nous avons 50 enregistrements par jour à raison de 7 jours semaine pour 52 semaines cela nous fais 18 200 enregistrements par année.
Si on utilise pour cette colonne un SmallInt, ceci veux dire que notre table va pouvoir contenir 1.8 année d’information ce qui est définitivement pas suffisant pour un système de gestion d’information.  Si on utilise un Int alors elle pourra contenir 117 993 années d’information ce qui est plus que suffisant.

Dans le cas des valeurs de clé primaire “auto-number” on peut ce permettre d’utiliser des types de données non-signé (unsigned). Ceci nous permet de contenir deux fois plus d’information dans le même type de données.

Nous pourrions aussi toujours mettre un format de données Int ou Bigint cependant nous ne pourrions pas considérer que notre travail est bien fait et optimal.

Le nom des champs

La nomenclature des champs est importante et doit être standardisée dans l’entreprise. Donc pour faciliter la lecture, il est préférable que la première lettre de chaque mot soit en majuscule sauf pour le premier mot de la séquence. Ceci permet une meilleure lecture des titres et n’a pas l’inconvénient de prendre plus d’espace comme la méthode des traits de soulignement “_”.

Par exemple, numeroEvenement et non Numero_Evenement.

Conclusion

On doit toujours évaluer au meilleur de notre connaissance les données que nous traitons pour fournir les systèmes les plus performants possible avec la meilleure configuration possible.

Note les types de valeurs représentent SQL Server 2000.

Bonne programmation