0% ont trouvé ce document utile (0 vote)
23 vues22 pages

Normes de Programmation SQL SERVER

Ce document établit des normes de programmation pour les bases de données SQL Server. Il couvre des thèmes tels que la conception logique et physique des bases de données, la nomination des objets, les recommandations de programmation T-SQL, et les politiques pour le passage des objets entre les environnements de développement et de production. Il désigne des responsables pour garantir le respect des normes.

Transféré par

ScribdTranslations
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
23 vues22 pages

Normes de Programmation SQL SERVER

Ce document établit des normes de programmation pour les bases de données SQL Server. Il couvre des thèmes tels que la conception logique et physique des bases de données, la nomination des objets, les recommandations de programmation T-SQL, et les politiques pour le passage des objets entre les environnements de développement et de production. Il désigne des responsables pour garantir le respect des normes.

Transféré par

ScribdTranslations
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

MDP Consulting

Manuel des normes de programmation


SERVEUR SQL
Normes de programmation

Table des matières

1 INTRODUCTION.1
1.1 Description. ....................................................................................................1
1.2 Objectif des Normess .............................................................................1
1.3 Personnel Responsable
2 BASE DE DONNÉES.3
2.1 Politique Générales..............................................................3
2.1.1 Passer de Développement à Production...............................................................3
2.2 Test des objets de base de données...............................................................5
2.3 Recommandations de programmation ..............................................................5
3 CONCEPTION DE LA BASE DE DONNÉES.6
3.1 Généralités ................................................................................................6
3.2 Règles pour nommer des tableaux ..........................................................................8
3.3 Règles pour nommer le champs........................................................................9
3.4 Règles pour nommer les Procédures Stockéess ....................................10
3.5 Règles pour nommer les Fonctions...................................................................11
3.6 Règles pour nommer le Trigger. .......................................................................12
3.7 Règles pour nommer les Jobs............................................................................12
3.8 Règles pour nommer les VUES. ................................................................13
3,9 Format pour documenter des objets. ...............................................................13
4 RECOMMANDATIONS
4.1 CONSEIL pour la programmation en T-SQL.................................................................17
Lecturea .....................................................................................................17
4.1.2 Jointures.........................................................................................................17
4.1.3 Où ......................................................................................................18
4.1.4 Généraux ................................................................................................19
4.1.5 Transaccionalitéd....................................................................................19

Gestion et Administration - TI Page : 2


Normes de programmation

1 Introduction

1.1 Description
Le présent manuel des normes comprend les normes de normes techniques
applicables à la conception logique, à la conception physique et à la construction de la base de données et du système
de sécurité dans l'environnement Microsoft SQL et les outils de développement
Microsoft Visual Studio.

Le contenu du manuel doit évoluer au rythme des besoins de


développement d'applications, le niveau d'implantation des méthodologies de développement et
la pratique elle-même, c'est pourquoi son objet principal est d'être le document cadre qui
À tout moment, collectez de manière actualisée les normes qui sont considérées.
applicables.

Il est indiqué ci-dessous le contenu de l'objet des normes, le personnel


responsable de chacune des zones où sont organisés les normes définies et
pour finir, l'organisation générale et les normes typographiques couramment
utilisées tout au long du manuel.

1.2 Objectif des Normes

L'objectif ou le but de la définition et de l'application des normes est de


suivants :
Garantir l'application d'un niveau minimum de qualité dans les systèmes de
information.
Fournir une approche cohérente et un langage commun dans les environnements avec
plusieurs équipes de développement.
Obtenir que les composants des systèmes d'information soient plus
faciles à comprendre et à entretenir.
Faciliter le processus d'introduction du nouveau personnel de développement.

Personnel Responsable

Il est de la responsabilité de chacun des membres des équipes de travail de


développe l'application conséquente des règles contenues dans ce Manuel, ainsi
comme de son entretien, en fonction des nouvelles circonstances ou besoins.
En particulier, l'interprétation, l'application et le maintien corrects correspondants,
selon les domaines aux personnes suivantes :

Administrateur de Base de Données


Conception physique de la base de données
Index
Clusters
Base de Données

Gestion et Administration - TI Page : 1


Normes de Programmation
Espace de Tables
Segment de Rollback
Synonymes

Analyste
Conception logique de base de données
Tableaux
Champs
Restriction des tables
Vues
Vues matérialisées
Séquences

Conception de modules d'application


Modulo
Paramètres
Structure de Données
Déclencheurs
Utilisation des données
Interfaces

Systèmes de sécurité
Utilisateurs
Groupes et Hiérarchies
Privilèges
Audit
Programmeur
Langage T-SQL
Langage ASP-NET
Services de rapport

Gestion et Administration - TI Página: 2


Normes de programmation

2 Base de Données

2.1 Politiques Générales

2.1.1 Passage du développement à la production

Le DBA ou responsable examinera le respect des caractéristiques


que doit avoir chaque objet (définis dans le document), par exemple
format de noms, Clés primaires, relations entre tables, types de
données, entre autres.

Le passage à la production doit être planifié, s'il s'agit d'un module


nouveau, informer par un courriel le responsable ou DBA avec
moins 8 heures d'avance pour réaliser un plan pour le passe.

S'il s'agit d'un ancien module, informer par e-mail le


responsable ou DBA de préférence avec au moins 1 heure d'avance
et inclusivement immédiatement, en fonction de l'urgence pour
procéder à évaluer les nouveaux objets créés pour enregistrer dans la base
de données.

Tout objet de base de données nouvel qui a été créé sans avoir
informé au responsable ou DBA, seront supprimés sans préavis
communication, et l'analyste système sera informé avec
copiez à la direction par le biais d'un e-mail indiquant l'action réalisée.

Le responsable ou DBA est obligé de surveiller le


performance des nouveaux objets créés en production au moins
pour une période de 2 semaines, afin de garantir la disponibilité des
systèmes maximisant les temps de réponse côté utilisateur
final.

L'analyste de systèmes, avant de demander le passage en production, est dans le


obligation d'avoir réalisé tous les tests pertinents au cas,
revisant soigneusement le temps de réponse, erreurs de
programmation, impact sur d'autres systèmes, entre autres contrôles que
chaque analyste juge approprié de réaliser.

Si les nouveaux objets que l'on souhaite mettre en production ne répondent pas
avec ce qui est spécifié dans le document, l'Analyste Système est dans le
obligation de réaliser les changements ou les améliorations suggérés par le
responsable ou DBA.

S'il s'agit d'objets anciens dans la base de données, où l'analyste


des systèmes détectent qu'une mauvaise pratique de programmation a été utilisée
(Par exemple : SELECT * FROM nom_table), l'analyste peut
réaliser le changement sans communication préalable, la seule chose que vous devez faire est

Gestion et Administration - TI Page : 3


Normes de programmation
spécifier selon le format les changements apportés à l'objet, et se
doit garantir que la fonctionnalité soit correcte, par la suite au
Le DBA recevra un courriel émis par le serveur indiquant le changement dans
l'objet et cela doit être de la responsabilité de vérifier.

Le passage à la production doit être effectué dans les premières heures de la journée, de
du lundi au vendredi de 8 h à 15 h au maximum, dans le but de
garantir la présence de l'analyste système en cas d'existence d'un
incident.

La programmation des procédures stockées, des fonctions et


Les déclencheurs doivent maintenir un ordre dans le codage en utilisant des TABULATIONS,
les sentences doivent se différencier les unes des autres et visuellement
faciliter la compréhension de la logique mise en œuvre.

Exemple

. Éviter l'exécution de requêtes dans l'environnement de production, pour cela


il y aura un environnement de QA avec une fréquence de mise à jour quotidienne,
Le manquement sera signalé à la direction.

Gestion et Administration - TI Page : 4


Normes de Programmation

2.2 Tester les objets de base de données

Le responsable ou DBA est dans l'obligation de réaliser un test sur les objets.
qui passeront en production, qu'ils doivent respecter les suivantes
spécifications :

L'exécution d'une procédure stockée de type INSERT ou


La mise à jour ne doit pas prendre plus d'une seconde, de préférence elle doit
être zéro.

L'exécution d'une procédure stockée de type SELECT ne


cela doit prendre plus de 2 secondes, de préférence cela doit être zéro.

S'il s'agit d'une procédure stockée qui sera exécutée par un


LES EMPLOIS, il sera exécuté périodiquement dans la journée, cela ne doit pas passer
des 3 secondes.

S'il s'agit d'une procédure stockée qui sera exécutée par un


JOBS, il ne sera exécuté qu'une seule fois dans la journée, il ne doit pas dépasser les
10 secondes et doit être programmé à une heure de la nuit, où la
la quantité d'utilisateurs connectés est minimale.

Les objets de la base de données doivent être dans un champ de


affaires (Tableau 002), si le nouveau module appartient à un domaine qui n'est pas
enregistré, le DBA est dans l'obligation d'enregistrer la nouvelle donnée.

2.3 Recommandations de programmation

Il n'est pas recommandé d'utiliser la requête "SELECT * FROM NomTable".


mentionner les colonnes que l'on souhaite visualiser.

Il ne faut pas effectuer un "SELECT COUNT (*) FROM NomTable", c'est


il est recommandé d'utiliser la colonne de clé primaire pour effectuer le comptage
SELECT COUNT (LlavePrimaria) FROM NombreTabla

Il existe des cas où une requête est effectuée sur la même table dans le
SÉLECTIONNER
SÉLECTIONNER columna1, (SÉLECTIONNER columna5 DE Tabla1 OÙ
columna9=522) comme columna5, columna6 FROM Tabla1 columna9=522
il est recommandé d'utiliser un LEFT JOIN.

Pour l'utilisation de tables temporaires, la quantité de données qu'elles doivent contenir


ne doit pas dépasser 5000 enregistrements, car cet objet utilise
exclusivement de la mémoire.

Réduire l'utilisation des curseurs, sauf s'il s'agit du dernier recours.

Gestion et Administration - TI Page : 5


Normes de programmation
Si la requête est une combinaison de plusieurs tables, il faut générer un premier
Sélectionner avec la table principale et obtenir la quantité de données requises et
Ensuite, procéder à les relier aux autres tableaux.

Les noms réservés s'écriront toujours en MAJUSCULES et les


attributs de tables en minuscules.

3 Conception de la base de données

3.1 Généralités

Les objets de base de données existent une nomenclature générique, identifiant


le type d'objet, le domaine d'activité et le nom de l'objet.

Nomenclature :

<Type d'objet>_<Domaine d'activité>_<Nom de l'objet>

Les noms des objets de base de données doivent être au singulier et


en minuscule.

Exemple :

tb_ges_cliente, (il est erroné de mettre tb_ges_clientes)

Dans le cas où le nom de l'objet est un nom composé, il doit être


de utiliser la nomenclature camel, celui-ci doit commencer par une lettre minuscule
YlasSiguientesPalabrasIniciarConMayúsculaSinSeparaciónAlguna.

Exemple :

tb_ges_soldeJournalier

Les noms d'objets ne doivent pas contenir d'articles ou de pronoms.

Exemple
La table des "Transactions des clients" serait appelée de la
forme suivante :

tb_ges_transactionClient

J'exclus l'article et chaque mot a été placé dans


minuscules.

Gestion et Administration - TI Page : 6


Normes de Programmation
Le nom choisi doit être le plus descriptif possible, en évitant
termes ambigus ou susceptibles de diverses interprétations, le
la taille totale du nom de l'objet ne doit pas dépasser 32 caractères.

Les objets connexes doivent être séparés par le symbole _ et nommés


en utilisant les noms à l'envers, en suivant un ordre logique de
phrase.

Exemple :

Tableau « Adresse des Clients »

tb_ges_client_direccion

Liée à la table tb_ges_client

Hormis les mots composés, la nomenclature camel case est utilisée.


(exemple : soldeJournalier l'espace blanc est annulé et le suivant
mot commence par une majuscule, ne pas utiliser le symbole « _ » pour séparer les
mots).

Utiliser le symbole_ dans les noms des objets identifie une dépendance.
Par exemple, la tb_ges_cliente_direccion est liée à la table
tb_ges_cliente et détaillez les adresses du client (un à plusieurs).

idée
Type d'objet Description
Objet
Table de destination, dont la source est d'origine
Td Table SQL
d'une source externe de données (ETL)
Table de base de configuration ou maîtresses
Tb Table SQL
internes propres à l'application
Table de regroupement, originaire comme un
Ta Table SQL résumé d'une ou plusieurs tables de destination, pour
optimiser l'émission des rapports.
Table temporaire, utilisée pour stocker
temporairement les données dans un
Tt Table SQL traitement ou génération de rapports
le contenu peut être supprimé dans
processus de nettoyage.
Table intermédiaire, image d'une table
source externe, utilisée pour accélérer la
Ti Table SQL
charger et utiliser des procédures stockées
transformez les données dans le processus ETL
Tk Table SQL Sauvegarde des tables

Pourquoi Index SQL Indice primaire


Ak Index SQL Index alternatif

Gestion et Administration - TI Page : 7


Normes de programmation
Type de
Objet SQL Description
Objet
Fk Contraintes SQL Indice étranger
Dg Diagramme SQL Diagrammes de relation d'entité
Magasin SQL
haut Procédures stockées
Procédure
Fn Fonction SQL Fonctions
Jo EMPLOI SQL Jobs de agenda de exécution
Rp FICHIER ASP.NET Fichier de rapports (SSRP)
Ap FICHIER ASP.NET Fichier de programmes (aspx)
Le FICHIER ASP.NET Fichier ETL (SSIS)
Fichiers comme des feuilles Excel ou des fichiers
Fi FICHIER
textes
Sc Script SQL Fichier Script d'exécution de commandes

Domaine du
Description
Affaires
ges Gestion
gén Procédures et fonctions générales
seg Sécurité
tar Tâches d'exécution d'ETL
Systèmes, pour l'utilisation de la documentation et des procédures
sœur générales comme utilitaires de développement ou
entretien.
ren Rentabilité
sperme Suivi des indicateurs de conformité
cua Carnet de gestion
avant Système budgétaire (bifopres)
spr Suivi des propositions
Tout autre domaine d'affaires doit être inscrit à
*
la table de tb_seg_aplicacion

3.2 Règles pour nommer les tables

Les tables doivent être créées selon leur représentation conceptuelle dans le
champ d'activité qui permet de les organiser et de faciliter leur localisation, en utilisant le
nomenclature générale définie au paragraphe 3.1 :

La quantité de colonnes d'un tableau ne doit pas être supérieure à 32


colonnes, cela permettra de ne pas avoir des colonnes qui ne sont valables que pour
certains enregistrements et le chargement des données dans une requête seront plus
rapide.

Toute table doit avoir un ou plusieurs champs clés 'PRIMARY KEY'.

Gestion et Administration - TI Page: 8


Normes de programmation

Les champs clés doivent être situés au début de la définition de la table


(ils doivent être les premiers).

Toute relation entre les tables doit être mise en œuvre par des contraintes.
(clés étrangères) avec intégrité référentielle.

3.3 Règles pour nommer les champs

Les champs sont libres et il faudra être aussi explicite que possible, utiliser des tirets
pour séparer les mots et ne pas dépasser 32 caractères, n'utilisez pas de caractères
spéciaux comme des mots accentués, eñe ou des symboles, les noms doivent être
être au singulier.

Il existe des préfixes qui résument le premier mot du champ, ils ont 3 caractères.
que indiquent la fonction du champ et les autres caractères qui expriment le détail,
toujours écrite en minuscules, cette norme doit prévaloir car le
Il sera utilisé dans l'environnement de développement et aidera à réduire le temps
dans le contrôle de suivi.

Préfixe Description
peut Quantité
morue Code
des Description
dir Adresse
est État
féc Date
grp Groupe
idée Identifiant
imp Importer
nom Nom
num Numéro
par Pourcentage
truc Type
tot Total
var Variation

Les champs doivent être au format XXX_<champ>, c'est-à-dire


Exemples :

Code du client.
Adresse du client.

Gestion et Administration - TI Page: 9


Normes de programmation

3.4 Règles pour nommer les procédures stockées

Le nom de la procédure stockée doit indiquer avec l'identifiant de


procédure up.

Le nom de la procédure stockée doit indiquer le domaine d'activité auquel


quel est le processus affecté.

Le nom de la procédure stockée doit indiquer l'action qu'elle va


générer, les actions autorisées sont les suivantes :

Préfixe Action Description


sel Lister Afficher une liste des données.
bol alimentaire
Créer Enregistrer les données dans la base de données.

Réaliser plusieurs processus, exemple


pro Traiter
calcul des moyennes
Afficher une liste des données, que
représenter
Lister
sa source pour un rapport

Tableau 003 : Actions pour les SP

Si la procédure fait référence à une seule table, celle-ci doit avoir le


même nom de la table, auquel on ajoute l'action dans le domaine
de commerce et le nom.

Exemple :

La table s'appelle tb_gen_balanza et nous allons créer le SP pour l'enregistrement.


le nom du SP sera : up_gen_upd _balanza

Si la procédure fait référence à plusieurs tables, le SP doit avoir le


Domaine d'activité du tableau principal, puis l'action est spécifiée
suivi du nom de la table principale et ensuite le nom résumé du
événement.

Exemple :

On nous demande de visualiser les clients débiteurs, et la table clients s'appelle


td_ges_cliente, le SP doit s'appeler up_ges_sel_clientDeudores.

Il existe certaines exceptions où la procédure fait référence à


plusieurs tables, le SP doit avoir le périmètre d'affaires "ges", puis il
spécifie l'action puis le nom abrégé de l'événement selon
l'interprétation de l'analyste de systèmes.

Exemple :

On nous demande de visualiser les clients débiteurs et combien de factures ont été émises, le SP
doit s'appeler up_ges_sel_deudaCantidadFactura.

Gestion et Administration - TI Page : 10


Normes de programmation

La quantité de caractères du nom d'un SP doit être inférieure ou égale à


32 caractères.

La quantité de colonnes à retourner d'un SP doit être inférieure ou égale à 32


colonnes.

La relation entre les mots dans le nom d'un SP doit commencer par
minuscule et ne doit pas être séparé par des traits d'union, la séparation de
PalabrasEsConMayúscula (estiloCamel)

Exemple : up_ges_sel_deudaQuantitéFacture.

3.5 Règles pour nommer les Fonctions.

Vous devez identifier le secteur d'activité dans lequel la fonction sera utilisée, si
c'est une fonction générale, utiliser le domaine "gen".

Dans le nom d'une FONCTION, il faut indiquer l'action que celle-ci va effectuer.
générer, les actions autorisées sont les suivantes :

Action Description
sel Afficher une liste des
données.
Utilisé pour des fonctions
SQL type Table-Value
cal Retourne un résultat de
une opération.
Tableau 004 : Actions pour les Fonctions

Le nom de la fonction doit commencer par le préfixe "fn" en minuscules,


suivi d'un tiret, l'action à générer est ajoutée (cadre précédent)
et ensuite on ajoute un nom qui décrira plus en détail l'événement
et doit commencer par une lettre majuscule.

Exemple :

Il est nécessaire de lister les états d'un champ et il est nécessaire que ce soit
à travers une fonction, le nom doit être : fn_ges_sel_estado.

Il est nécessaire d'effectuer l'addition de deux nombres et il est nécessaire que ce soit
à travers une fonction, le nom doit être : fn_gen_cal_sumaNumero.

La quantité de caractères du nom d'une FONCTION doit être


moins ou égal à 32 caractères.

Gestion et Administration - TI Page : 11


Normes de programmation
Le nombre de colonnes à retourner d'une fonction doit être inférieur ou
égal à 16 colonnes.

La relation entre les mots dans le nom d'une fonction doit commencer
con majuscule et ne doit pas être séparé par des tirets.
Exemple : fn_gen_cal_sumaNumero.

3.6 Règles pour nommer les déclencheurs.

Dans le nom d'un déclencheur, il doit être indiqué l'action lors de laquelle il va être exécuté,
les actions autorisées sont les suivantes :

Action Description
ins Il sera exécuté lorsqu'un INSERT sera effectué.
mise à jour S'exécutera lors d'une mise à jour.
del S'exécutera lors d'un DELETE.
cud Il sera exécuté lors d'un insert, d'une mise à jour ou
supprimer.

Le nom du Trigger doit commencer par le préfixe "tr" en minuscule,


suivi d'un tiret, puis l'identifiant du domaine d'affaires (le
même que utilise le tableau), suivi d'un tiret, puis de l'action que
réalise et finalement le nom de la table (sans le préfixe de l'entreprise).

Exemple :

Il faut créer le Trigger pour la table tr_ges_balanza quand se


insérez, le nom doit être : tr_ges_ins_balanza.

Il est nécessaire de créer le trigger pour la table tb_vta_factura lorsque se


éliminez les données, le nom doit être : tr_vta_del_factura.

3.7 Règles pour nommer les emplois.

Le nom d'un JOBS doit commencer par le préfixe "jb", suivi de un


scénario, puis ajouter le code de l'application affectée et enfin
nom qui décrit brièvement l'objectif de celui-ci.

Exemple :

Il est nécessaire de créer les jobs pour supprimer les enregistrements nuls de la table
tb_vta_factura, le nom pourrait être :
jb_ supprimerEnregistrementNulFact.

La quantité de caractères du nom d'un JOBS doit être inférieure ou


égal à 32 caractères.

Gestion et Administration - TI Page : 12


Normes de programmation

3.8 Règles pour nommer les VUES.

Le nom d'une vue doit commencer par le préfixe "vw" en minuscules,


suivi d'un tiret, puis le nom du domaine d'activité, et
finalement le nom qui décrit brièvement l'objectif de
même, rappelez-vous qu'ils doivent être au singulier.

Exemple :

Il est nécessaire de créer une vue pour lister les enregistrements des clients avec
facture le nom pourrait être : vw_ges_clientNouveau.

La quantité de caractères du nom d'une vue doit être supérieure à


32 caractères.

La relation entre les mots dans le nom d'une vue doit commencer
con minuscules et ne doit pas être séparé par des tirets.

Exemple : vw_ges_clientVinculado

3.9 Format pour documenter les objets.

Les procédures stockées, fonctions et déclencheurs doivent posséder


obligatoirement un détail de sa raison d'existence, ce format
permettra de connaître en détail les changements qui ont été apportés aux
objets au fil du temps.

Le format à suivre est le suivant, et doit être après le mot


en tant qu'objet.

-- =============================================
-- Auteur : jmieses
-- Date de création : 06/02/2012
-- Description: Met à jour la maitrise de l'application
-- Mises à jour :
06/02/2013 fcossio @001 J'ajoute le champ
-- astuce_application
-- =============================================

Il doit être spécifié dans le code de l'objet le numéro de l'article où


le changement ou l'augmentation de fonctionnalité a été effectué.

-- DÉBUT @001
SÉLECTIONNER * DE tt_ges_prueba
-- FINAL @001

Gestion et Administration - TI Page : 13


Normes de Programmation

4 Recommandations

Les recommandations présentées ci-dessous ont été données par l'équipe de


Systèmes de gestion totale SAC et collectes par BANBIF :

L'optimisation des programmes dépend de qui développe le module et doit


s'appuyer sur la phrase "SET EXPLAIN" pour voir le plan d'exécution des requêtes.

Tout changement sur la BD (champ, table, index, etc.) doit être notifié à un
la personne responsable oDBA, qui à son tour notifiera le reste du personnel, est
recommandable l'utilisation d'un e-mail pour le contrôle.

Lorsque le besoin de supprimer complètement tout le contenu d'une table se présente, on


il est recommandé d'utiliser la commande TRUNCATE TABLE nombretable. Pour ces cas
Il ne faut pas utiliser la commande "DELETE FROM nombretabla" car cela fait un
parcours séquentiel du tableau pour le supprimer.

Entier vs. Smallint. Avantage : Taille de stockage et plage maximale. Dans le cas
del Integer a un stockage plus important car il fait 4 octets tandis que le smallint seulement
est de 2 octets.

Varchar vs Char. Avantage : Le stockage d'un char fait que le moteur de BD


remplir les espaces vides jusqu'à atteindre la longueur, dans le type varchar ne se
complète avec des espaces vides.

Décimal contre Flottant. Avantages : Décimal est un type de données propriétaire du moteur, les
Les opérations arithmétiques avec ce type sont d'abord traitées par le moteur, puis passent au
processeur, tandis que les opérations avec un float, integer et smallint sont effectuées
directement le processeur, cependant l'avantage de Decimal est la longueur dans les
décimales, c'est-à-dire qu'il effectue déjà la fonction de ronding lors de l'enregistrement, c'est pourquoi il est plus
usé

Création d'index. Avantages : Minimiser la quantité d'index dans une table optimise
l'accès aux données et au temps d'indexation. Dans une architecture de BD primaire et
secondaire, lorsqu'une opération de réindexation se produit, à la fin, toutes les pages
des index sont placés dans le tampon de réplication pour que la BD secondaire les reçoive.
Il est important de s'accorder au moment de la conception des index pour éviter que
durant la programmation, on redondit dans les indices. Éviter l'utilisation d'indices avec des champs.
de type Char dont la longueur est grande. Il est important de prendre en compte le volume de
informations de la table. Il est utilisé dans les filtres, Joins, Order By, Group By.

Clés primaires. Avantages : Les clés primaires créent un index de type UNIQUE,
renforce l'intégrité de l'information. Par définition de l'intégrité, les clés primaires
ils n'acceptent pas de nuls.

Clés étrangères. Avantages : Renforce l'intégrité de l'information. S'appuie sur


indices (type duplicé) dans les tables. En n'utilisant pas : A beaucoup de clés étrangères dans une table,
génère trop d'indices.

Gestion et Administration - TI Page : 14


Normes de Programmation

Valeurs par défaut. Avantages : Renforce l'intégrité de l'information en rendant que


sean stockés des valeurs par défaut et non des valeurs NULL. Le contrôle est assuré par la Base
de données et non de l'application.

Transactions. Advantages: Integrity and consistency of the data, the server guarantees
que les opérations effectuées dans les limites de la transaction sont complètes
sur le disque, ou en cas de défaillance pendant son exécution, la base de données se
restaurera au point avant l'exécution de la transaction. Le temps que se
maintenez le registre à jour, la transaction doit être minimale et ainsi y parvenir
plus de fréquentation et de disponibilité. Réplication cohérente. Ne pas utiliser : Lorsqu'un événement se produit
interruption d'une mise à jour de données, il n'est pas possible de garantir l'ampleur de l'opération
a été réalisée, même dans une opération d'un seul enregistrement, il n'est pas possible de savoir si les données
s'est mis à jour sur le disque correctement, ou si les index impliqués ont été mis à jour
correctement. Il existe même la possibilité de laisser les pages du disque
inconsistentes. Dans un environnement répliqué, il n'est pas garanti que le serveur secondaire
réflète les changements apportés au serveur principal. Dans les processus de lecture seule non
utiliser des transactions.

Transactions courtes. Avantages : Plus le temps d'un enregistrement est court


bloqué, plus de disponibilité des données pour les autres utilisateurs, ce qui implique
niveau de concurrence plus élevé. Les transactions restent ouvertes plus longtemps
dans le journal des transactions, retardant l'activité de sauvegarde, et donc moindre
disponibilité d'espace dans les journaux pour écrire plus de transactions, provoquant cette
transaction une Long Transaction, dans ce cas le processus est avorté par le gestionnaire,
et en fonction de la quantité de logs, l'activité pourrait être suspendue pour le
reste des utilisateurs, pendant que ce processus effectue le rollback.

Indices. Avantages : Dans un environnement de transactions en ligne, l'accès est important.


direct vers les données, le blocage des enregistrements individuellement et leur mise à jour directe
fournit un niveau de disponibilité supérieur à celui des autres enregistrements. La présence de
Les indices peuvent contribuer à réduire le temps de réponse. En n'utilisant pas : cela peut provoquer
une lecture séquentielle, ce qui n'est pas bénéfique s'il s'agit d'un environnement
transactionnel, où des temps de réponse minimaux sont requis.

Sélectionner les colonnes nécessaires dans une instruction SELECT. Avantages : Le


le gestionnaire a la capacité de lire à travers les pages d'index lorsque les
Les colonnes mentionnées sont celles qui interviennent dans un index en particulier, ce type de
la lecture est la plus rapide et efficace. En n'utilisant pas : Les tampons internes utilisés par le
les clients sont de taille fixe. Plus il y a de données sélectionnées, plus il y a de changements de contexte.
requerra pour envoyer les données du serveur au client. Remplir les tampons implique
un trafic accru entre le client et le processus du serveur, ce qui a un impact direct
dans la performance.

TODO la requête doit accéder aux tables en utilisant des index (sauf si le SQL décide de ne pas le faire)
les utiliser). Cela implique que TOUT tableau, y compris les temporaires, doit avoir un Index
Clusterisé. En option, il est possible de placer un ou plusieurs index NonClusterisés.

Gestion et Administration - TI Page : 15


Normes de programmation
Dans la clause WHERE, n'utiliser jamais de fonctions sur des colonnes. La fonction doit être
sur la constante avec laquelle on va comparer.

Exemple
Ne pas utiliser : WHERE CONVERT(VARCHAR(10),fec_poliza,121) = "20051201"
Utiliser : WHERE fec_poliza = CONVERTIR(DATETIME,"20051201",121)

Dans la clause WHERE, n'utilisez jamais d'opérateurs avec des colonnes d'une table. Les
opérateurs les placer sur la constante avec laquelle on va comparer.

Exemple
Ne pas utiliser : WHERE num_poliza + 600 = @variable_poliza
Usar : WHERE num_poliza = @variable_poliza - 600

Toute table temporaire doit être supprimée, il ne doit exister aucune table avec tt_ dans les bases de
Données de production.

Chaque procédure stockée doit contenir dans l'en-tête, le nom de l'auteur, la date et une
brève description de l'objectif du SP.

Évitez les requêtes dynamiques en concaténant des valeurs séparées par des virgules, comme par

Exemple
SUPPRIMER DE td_ges_direccion OÙ cod_direccion IN (#1, #2, #3,..#N)

Au lieu de cela, mettez les valeurs dans un tableau de manière à ce que cela puisse être fait.
croix avec d'autres tables, comme par

Exemple :

SUPPRIMER td_ges_direccion
DE DIRECCIONES, #tt_ges_temporal
OÙ td_ges_direccion.cod_direccion =
#tt_ges_temporal.cod_direccion

Gestion et Administration - TI Page: 16


Normes de programmation
4.1 ASTUCE pour la programmation en T-SQL

Lecture

Évitez d'utiliser SELECT *. Lisez toujours uniquement les colonnes dont vous avez besoin. Avec cela
évites d'apporter beaucoup de données inutiles au client, alors on
décongestionner le réseau et le client a l'impression que c'est plus rapide.

Pour les requêtes de listes d'enregistrements, utilisez l'opérateur TOP n. Avec cela
nous évitons d'apporter de nombreux enregistrements au client. Le réseau est également désengorgé.
et le client sent que c'est plus rapide.

Au lieu de SET ROWCOUNT n, utilise TOP n.

Si vous utilisez l'opérateur UNION et que vous êtes sûr que les deux requêtes n'ont pas
registres dupliqués, alors mieux vaut utiliser UNION ALL, pour éviter que
implicitement, l'opérateur DISTINCT est utilisé.

Évitez d'utiliser SELECT ... INTO table_name. Cela bloquera les tables du système.
Au lieu de cela, crée d'abord les tables puis réécris la phrase.
comme INSERT INTO nom_de_table SELECT ...

Si vous allez lire des données d'une seule table, évitez de le faire en utilisant des vues qui utilisent
autres tables.

4.1.2 Jointures

Écrivez des Jointures au format ANSI (utilisez la clause JOIN .. ON). Avec cela, vous vous assurez
d'écrire toutes les restrictions sans possibilité d'en oublier une.

Évite d'utiliser la même table plus d'une fois dans une seule requête. Pour améliorer cela, utilise
tables temporaires.

Il préfère utiliser un joint plutôt qu'un sous-requête.

Par exemple au lieu d'utiliser :

SÉLECTIONNER numéro_membre, prénom, nom_de_famille, numéro_chambre


DE membres
OÙ numéro_de_chambre
DANS (SÉLECTIONNER rooms.room_number DE rooms)

Gestion et Administration - TI Page : 17


Normes de Programmation

États-Unis
SELECT numéro_membre, prénom, nom, numéro_chambre
DE membres m
JOIN interne chambres r
ON m.room_number = r.room_number

Au lieu d'utiliser une requête avec de nombreux Joins où les tables impliquées sont
grandes, mieux créez une table temporaire avec les données de la table principale (codes)
et puis mets à jour ce tableau en effectuant des jointures avec les tables secondaires.

Au lieu d'utiliser la clause IN avec une sous-requête, utilisez une instruction


REJOINDRE.

Par exemple, au lieu d'utiliser

SELECT nom_éditeur
DE tb_gen_publisher
OÙ cod_publisher DANS
(SÉLECTIONNER cod_publisher DE tb_gen_title)

États-Unis

SELECT nom_publisher
DE tb_gen_publisher
INNER JOIN tb_gen_title
SUR tb_gen_title.cod_publisher = tb_gen_publisher.cod_publisher

4.1.3 Où

Évitez d'utiliser des fonctions sur les colonnes dans la clause WHERE

Par exemple au lieu d'utiliser

SÉLECTIONNER numéro_membre, prénom, nom_de_famille


DE membres
OÙ DATEDIFF(yy, datofbirth, GETDATE()) > 21

États-Unis

SÉLECTIONNER numéro_membre, prénom, nom_de_famille


DE membres
OÙ dateofbirth < DATEADD(yy,-21,GETDATE())

Si vous utilisez LIKE dans la clause WHERE, essayez d'utiliser au moins 3 caractères.
avance comme "abc%"

Si vous utilisez LIKE dans la clause WHERE, évitez d'utiliser l'opérateur % au début : "%abc"

Là où c'est possible, utilise la clause BETWEEN au lieu de IN

Gestion et Administration - TI Page : 18


Normes de programmation

Par exemple au lieu d'utiliser


SÉLECTIONNER numéro_client, nom_client
DE client
OÙ customer_number dans (1000, 1001, 1002, 1003, 1004)

États-Unis
Sélectionnez numéro_de_client, nom_du_client
DE la part du client
OÙ customer_number ENTRE 1000 et 1004

Évitez d'utiliser des concaténations dans les clauses WHERE

Évitez d'utiliser les opérateurs OR, NOT IN, NOT BETWEEN, <>, NOT EXISTS, NOT
COMME, COMME '%ABC'

Si une requête a un ou plusieurs opérateurs OU, envisagez de réécrire la requête en plusieurs


Interrogez et unissez les résultats en utilisant l'opérateur UNION. N'oubliez pas d'utiliser
UNION ALL, si possible.

4.1.4 Généraux

Évite d'utiliser des curseurs. Utilise plutôt des tables temporaires avec un champ entier.
identité(1,1) que vous pourrez balayer de manière séquentielle. N'oubliez pas d'indexer le champ
identité.

Considérez que les fonctions MIN et MAX peuvent utiliser des index. Si possible, créez.
indices sur les colonnes sur lesquelles ces fonctions sont utilisées.

Lorsque vous utilisez des tables temporaires, envisagez de créer des index pour augmenter le
performance de vos requêtes.

Vérifiez chaque requête d'une procédure stockée et assurez-vous qu'elle ne fasse pas de "table scan".
(recherche non indexée). Pour étudier cela, activez la directive « Afficher le plan de requête » dans
l'« Analyseur de requêtes ».

Chaque requête doit utiliser un index sur une colonne qui a une haute
dispersion.

Utilisez autant que possible des tables dérivées au lieu de tables temporaires. C'est plus
raisonnable si les informations que vous stockeriez dans la table temporaire vont être utilisées
une fois. Mais si tu penses utiliser ces données plusieurs fois dans une procédure stockée
procédure, il est donc préférable d'utiliser une table temporaire.

4.1.5 Transactionnalité

Gestion et Administration - TI Page: 19


Normes de Programmation
Ne jamais diviser une transaction en deux transactions invoquées
consécutivement depuis le client. Cela fait que si la deuxième transaction échoue, la
base de données est devenue corrompue.

Veille à ce que tes transactions soient petites, c'est-à-dire qu'elles accèdent au moindre
nombre de pages de la base de données.

Évite de déclarer une seule grande transaction pour les processus par lots. Il vaut mieux avoir
plusieurs petites transactions et gérer les reprosesses.

Évitez d'utiliser des transactions imbriquées.

Gestion et Administration - TI Page : 20

Vous aimerez peut-être aussi