hicucu/rdb-skill

Base de données relationnelle (Indépendante du moteur)

Présentation

Bonnes pratiques neutres pour les bases de données relationnelles. Les principes et motifs sont écrits une fois ; seuls les points où les dialectes SQL divergent (MSSQL vs MySQL/MariaDB) sont signalés en ligne ou rassemblés dans l'aide-mémoire des dialectes. Optimisez pour l'exactitude et le plus petit changement étayé par des preuves mesurées.

Quand l'utiliser

• Concevoir ou réviser un schéma (tables, clés, normalisation, types de données).
• Ajouter ou corriger des index ; diagnostiquer des requêtes lentes ou des scans complets de table.
• Lire un plan d'exécution pour identifier le goulot d'étranglement.
• Choisir ou dépanner l'isolation des transactions, le verrouillage ou les interblocages.
• Paginer de grands ensembles de résultats ; éliminer l'accès N+1.
• Planifier une migration de schéma sûre pour la production.

Pas pour : les approfondissements internes du moteur (internes du moteur de stockage comme le pool de buffers InnoDB, fonctionnalités propres au fournisseur, constructions T-SQL uniquement, topologie de réplication/partitionnement). Utilisez la documentation propre au moteur ou une compétence dédiée à un seul moteur.

Flux de travail

1. Établir d'abord le contexte. Quel moteur + version majeure ? Mélange lecture/écriture, volume de lignes, objectif de latence, OLTP vs analytique. Les conseils changent avec ces paramètres.
2. Lire uniquement la référence pertinente liée dans chaque section ci-dessous.
3. Proposer le plus petit changement qui résout le problème, avec ses compromis.
4. Valider avec des preuves — capturer un plan d'exécution et des métriques de temps et de lignes avant et après (voir references/execution-plans.md), pas des règles empiriques.
5. Pour la production, inclure un plan de rollback et une vérification post-déploiement.

Conception de schéma

• Modéliser les relations explicitement ; commencer normalisé (3FN/BCNF) et dénormaliser uniquement avec une raison mesurée. Chaque table a besoin d'une clé primaire stable.
• Choisir le type de données le plus étroit et correct ; contraindre les états invalides au niveau du schéma (NOT NULL, UNIQUE, CHECK, FK) plutôt que seulement dans le code applicatif.

Références : normalisation · clés-et-contraintes · types-de-données

Indexation

• Indexer les colonnes utilisées dans WHERE, JOIN et ORDER BY — par sélectivité, pas par devinette. Ordre des index composites : colonnes d'égalité d'abord, puis de plage/tri (règle du préfixe le plus à gauche). Un prédicat de plage arrête l'utilisation de l'index pour les colonnes suivantes.
• Les index couvrants évitent les accès à la table. Auditer et supprimer les index inutilisés/dupliqués ; chaque index pénalise les écritures.

Références : indexation · index-composites

Optimisation des requêtes

• Garder les prédicats SARGables — pas de fonctions/casts implicites sur les colonnes indexées dans WHERE. Sélectionner uniquement les colonnes nécessaires. Préférer EXISTS à IN (sous-requête), UNION ALL à UNION lorsque la déduplication n'est pas nécessaire, et grouper les écritures volumineuses.
• Utiliser la pagination par jeu de clés (cursor) au lieu de OFFSET important. Éliminer N+1 en groupant ou en joignant.

Références : optimisation-des-requêtes · plans-d-execution · pagination

Transactions et verrouillage

• Garder les transactions courtes ; effectuer les E/S et les travaux lents en dehors. Accéder aux lignes dans un ordre cohérent pour éviter les interblocages ; s'attendre à des interblocages et réessayer avec backoff.
• Connaître le niveau d'isolation par défaut de votre moteur (il diffère) et les anomalies que chaque niveau autorise. Utiliser les lectures verrouillantes (FOR UPDATE) délibérément, pas par habitude.

Références : transactions-et-isolation · verrouillage-et-interblocages

Migrations et DDL

• Effectuer les modifications de schéma de manière additive d'abord et rétrocompatibles ; étendre → remplir → contracter. Les DDL volumineuses/verrouillantes nécessitent une stratégie en ligne et un chemin de rollback.

Référence : migrations-et-ddl

Différences de dialecte du moteur

Auto-incrémentation, guillemets d'identifiant, pagination, upsert, fonctions de chaîne, heure courante, EXPLAIN et valeurs par défaut d'isolation divergent tous selon les moteurs. Confirmez la syntaxe pour le moteur cible avant d'écrire du SQL portable.

Référence : aide-mémoire-des-dialectes-de-moteur

Garde-fous

• Préférer les preuves mesurées (plans d'exécution, métriques) aux règles générales.
• Indiquer le moteur et la version majeure lorsque le comportement en dépend.
• Obtenir une approbation humaine explicite avant les opérations destructrices (DROP/DELETE/TRUNCATE ou toute migration non réversible). Toujours confirmer qu'une sauvegarde existe d'abord.