--- title: SQL description: "## 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.…" url: "https://wiki.biboard.fr/wiki/bonnes-pratiques-sql/" updated: "2026-05-19" category: Bonnes pratiques --- # SQL ## 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 ``` CLIENTFACTUREPRODUIT ``` ### À éviter ``` TAB1DATATMP ``` --- ## Colonnes Le nom doit décrire clairement l’information contenue. ### Bon exemple ``` ID_CLIENTDATE_FACTUREMONTANT_TOTAL ``` ### À éviter ``` ID1DATE1MNT ``` --- ## 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.PRENOMFROM CLIENT C ``` ### À éviter ``` SELECT X.NOM, X.PRENOMFROM 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, PRENOMFROM CLIENTWHERE VILLE = 'TOULOUSE' ``` ### À éviter ``` select nom, prenomfrom clientwhere 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.MONTANTFROM CLIENT CINNER JOIN FACTURE F ON F.ID_CLIENT = C.ID_CLIENTWHERE C.ACTIF = 1ORDER 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_CLIENTSFROM CLIENT ``` ### À éviter ``` SELECT COUNT(*) AS C1FROM 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, EMAILFROM 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 NOMFROM 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éfixe | Usage | | --- | --- | | `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_MENSUELLELOAD_CLIENT_ACTIFEXP_FACTURE_COMPTABLEMAIL_RELANCE_IMPAYEDWH_CA_JOURNALIER ``` --- # Ajouter une description métier Le nom doit permettre de comprendre rapidement le contenu ou l’objectif fonctionnel. ## Bon exemple ``` REP_STOCK_ARTICLEREP_CA_COMMERCIALLOAD_FACTURE_CLIENT ``` ## À éviter ``` REP_TESTREQ1LOAD_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 | Suffixe | Signification | | --- | --- | | `_PARAM` | Requête paramétrée | | `_P` | Version courte | | `_DATE` | Paramètre de date | | `_USER` | Paramètre utilisateur | L’important est surtout de garder une convention cohérente dans tout le projet. --- ## Exemple ``` REP_CA_MENSUEL_PARAMREP_STOCK_PMAIL_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_DATEREP_DUMMY_PARAM ``` ## Requête de contrôle ``` CTRL_DOUBLON_CLIENTCTRL_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_SOURCEREP_VENTE_MENSUELLEEXP_VENTE_COMPTABLEMAIL_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.