View Categories

SQL

Table des matières

Objectif #

Le SQL permet d’interroger et de manipuler les données d’une base.
Même si une requête fonctionne, une écriture claire et structurée facilite :

  • la lecture,
  • la maintenance,
  • la correction d’erreurs,
  • le travail en équipe.

L’objectif n’est pas d’écrire du SQL “expert”, mais du SQL simple, lisible et cohérent.

1. Nommer clairement les objets #

Tables #

Utiliser des noms explicites représentant le contenu de la table.

Bon exemple #

CLIENT
FACTURE
PRODUIT

À éviter #

TAB1
DATA
TMP

Colonnes #

Le nom doit décrire clairement l’information contenue.

Bon exemple #

ID_CLIENT
DATE_FACTURE
MONTANT_TOTAL

À éviter #

ID1
DATE1
MNT

Alias #

Les alias servent à raccourcir les noms dans les requêtes.

Privilégier des alias courts mais compréhensibles.

Bon exemple #

SELECT
    C.NOM,
    C.PRENOM
FROM CLIENT C

À éviter #

SELECT
    X.NOM,
    X.PRENOM
FROM CLIENT X

2. Mettre les mots-clés SQL en majuscules #

Les mots-clés SQL doivent être facilement visibles dans la requête.

Bon exemple #

SELECT
    NOM,
    PRENOM
FROM CLIENT
WHERE VILLE = 'TOULOUSE'

À éviter #

select
    nom,
    prenom
from client
where ville = 'TOULOUSE'

3. Indenter correctement les requêtes #

Une requête bien indentée est beaucoup plus simple à comprendre.

Recommandations #

  • Une ligne par colonne dans le SELECT
  • Les clauses principales alignées
  • Les conditions complexes séparées

Bon exemple #

SELECT
    C.NOM,
    C.PRENOM,
    F.DATE_FACTURE,
    F.MONTANT
FROM CLIENT C
INNER JOIN FACTURE F
    ON F.ID_CLIENT = C.ID_CLIENT
WHERE C.ACTIF = 1
ORDER BY F.DATE_FACTURE DESC

4. Limiter les lignes trop longues #

Éviter les requêtes écrites sur une seule ligne.

À éviter #

SELECT NOM, PRENOM, VILLE FROM CLIENT WHERE ACTIF = 1 ORDER BY NOM

Une requête aérée est plus simple à lire et à modifier.

5. Utiliser des alias de colonnes explicites #

Les alias permettent de rendre les résultats plus compréhensibles.

Bon exemple #

SELECT
    COUNT(*) AS NB_CLIENTS
FROM CLIENT

À éviter #

SELECT
    COUNT(*) AS C1
FROM CLIENT

6. Commenter les traitements complexes #

Ajouter un commentaire lorsque la logique métier n’est pas évidente.

Exemple #

/* Calcul du montant TTC avec remise commerciale */
SELECT
    MONTANT_HT * 1.20 * (1 - REMISE)
FROM FACTURE

Attention dans BiBOARD #

Dans les ACTION_SQL BiBOARD, les commentaires avec -- peuvent poser problème car les retours à la ligne sont supprimés.

Privilégier les commentaires de type :

/* Commentaire */

7. Éviter les SELECT * #

Le SELECT * récupère toutes les colonnes de la table, même celles inutiles.

Cela peut :

  • ralentir les traitements,
  • compliquer la lecture,
  • provoquer des erreurs après modification de la table.

Bon exemple #

SELECT
    NOM,
    PRENOM,
    EMAIL
FROM CLIENT

À éviter #

SELECT *
FROM CLIENT

8. Garder une logique simple #

Une requête trop complexe devient difficile à maintenir.

Conseils #

  • Découper les traitements si nécessaire
  • Utiliser des CTE pour clarifier les étapes
  • Éviter les imbrications excessives

Exemple avec CTE #

WITH CLIENT_ACTIF AS (
    SELECT
        ID_CLIENT,
        NOM
    FROM CLIENT
    WHERE ACTIF = 1
)

SELECT
    NOM
FROM CLIENT_ACTIF

9. Être cohérent #

Le plus important est de garder les mêmes règles dans tout le projet :

  • même style d’écriture,
  • même indentation,
  • mêmes conventions de nommage.

La cohérence améliore fortement la lisibilité globale.

Résumé des bonnes pratiques #

  • Utiliser des noms explicites
  • Mettre les mots-clés SQL en majuscules
  • Indenter les requêtes
  • Éviter les lignes trop longues
  • Ajouter des commentaires utiles
  • Éviter les SELECT *
  • Utiliser des alias clairs
  • Simplifier les traitements complexes
  • Garder un style cohérent dans tout le projet

10. Nommage des requêtes SQL #

Dans BiBOARD, le nom d’une requête est important.
Il permet de comprendre rapidement son objectif, son usage et son contexte sans devoir ouvrir le SQL.

Un nom clair facilite :

  • la maintenance,
  • la recherche des requêtes,
  • le travail en équipe,
  • l’identification des dépendances.

Utiliser un préfixe selon l’usage #

Il est recommandé d’utiliser un préfixe indiquant le rôle de la requête.

Exemples de préfixes #

PréfixeUsage
REP_Requête utilisée dans un tableau croisé dynamique (TCD) ou reporting
LOAD_Chargement ou préparation de données
DWH_Requête liée au Datawarehouse
EXP_Export de données
MAIL_Source utilisée dans un envoi de mail
TMP_Requête temporaire ou de test
CTRL_Contrôle ou vérification de données

Bon exemple #

REP_VENTE_MENSUELLE
LOAD_CLIENT_ACTIF
EXP_FACTURE_COMPTABLE
MAIL_RELANCE_IMPAYE
DWH_CA_JOURNALIER

Ajouter une description métier #

Le nom doit permettre de comprendre rapidement le contenu ou l’objectif fonctionnel.

Bon exemple #

REP_STOCK_ARTICLE
REP_CA_COMMERCIAL
LOAD_FACTURE_CLIENT

À éviter #

REP_TEST
REQ1
LOAD_NEW

Identifier les requêtes avec paramètres #

Lorsqu’une requête utilise des paramètres, il peut être utile de le préciser dans le nom.

Recommandations possibles #

SuffixeSignification
_PARAMRequête paramétrée
_PVersion courte
_DATEParamètre de date
_USERParamètre utilisateur

L’important est surtout de garder une convention cohérente dans tout le projet.

Exemple #

REP_CA_MENSUEL_PARAM
REP_STOCK_P
MAIL_RELANCE_DATE

Identifier les requêtes techniques ou spécifiques #

Certaines requêtes ont un usage purement technique.
Il peut être utile de le rendre visible dans le nom.

Requête basée sur une table DUMMY #

Exemple :

TMP_DUMMY_DATE
REP_DUMMY_PARAM

Requête de contrôle #

CTRL_DOUBLON_CLIENT
CTRL_FACTURE_SANS_LIGNE

Une requête par usage ou une requête mutualisée ? #

C’est un point important dans BiBOARD.

Requête unique mutualisée #

Une seule requête peut alimenter plusieurs usages :

  • reporting,
  • export,
  • mail,
  • Datawarehouse.

Avantages #

  • moins de duplication,
  • maintenance centralisée.

Inconvénients #

  • requête plus complexe,
  • risque d’impact sur plusieurs usages,
  • performances parfois moins adaptées.

Requêtes séparées par usage #

Créer une requête dédiée pour chaque besoin :

  • une requête pour le TCD,
  • une pour le Datawarehouse,
  • une pour les exports,
  • etc.

Avantages #

  • logique plus claire,
  • optimisation adaptée au besoin,
  • maintenance plus simple fonctionnellement.

Inconvénients #

  • duplication possible,
  • plusieurs requêtes à maintenir.

Recommandation générale #

Dans BiBOARD, il est souvent préférable de :

  • mutualiser uniquement les traitements réellement communs,
  • créer des requêtes dédiées lorsque les usages deviennent différents.

Exemple #

À éviter #

Une seule requête très complexe qui :

  • alimente un TCD,
  • génère un export,
  • sert pour un mail,
  • recharge un Datawarehouse.

Préférable #

LOAD_VENTE_SOURCE
REP_VENTE_MENSUELLE
EXP_VENTE_COMPTABLE
MAIL_VENTE_ANOMALIE

Chaque requête a alors :

  • un objectif clair,
  • une responsabilité unique,
  • une maintenance plus simple.

Conseils complémentaires #

Éviter les noms trop longs #

Le nom doit rester lisible.

Préférable #

REP_CA_AGENCE

À éviter #

REP_CHIFFRE_AFFAIRE_GLOBAL_PAR_AGENCE_ET_PAR_PERIODE

Garder une convention stable #

Le plus important est que toute l’équipe applique les mêmes règles :

  • mêmes préfixes,
  • mêmes suffixes,
  • même structure de nommage.

La cohérence est plus importante que la convention elle-même.

Retour en haut