Base de donnée (BDD)

À quoi sert une base de données ? Une base de données sert à stocker, organiser, retrouver et protéger des informations. C’est le “coffre-fort” de ton application : utilisateurs, articles, commandes, logs, messages… tout ce qui doit rester fiable et durable. ℹ️ En 1 phrase Une base de données permet de gérer des données de façon structurée, performante et sécurisée, même avec plusieurs utilisateurs en même temps. Ce qu’elle t’apporte concrètement Persistance : les données restent après redémarrage Recherche rapide : filtres, tri, index, pagination Cohérence : contraintes (NOT NULL, UNIQUE, clés étrangères) Concurrence : plusieurs accès simultanés sans corruption Sécurité : comptes, droits, audit, chiffrement (selon config) Backup & restauration : indispensable en production SQL ou NoSQL : que choisir ? Dans la majorité des projets “classiques” (gestion, contenu, e-commerce, admin, API), un SGBD relationnel (SQL) est le meilleur choix. 💡 Règle simple Si tu as des relations (utilisateur → articles → commentaires) et besoin d’intégrité, prends SQL (MySQL/MariaDB/PostgreSQL). SQL (relationnel) ✅ Tables, relations, contraintes (intégrité forte) ✅ Transactions (cohérence) ✅ Très adapté aux données structurées NoSQL (documents/clé-valeur…) ✅ Flexible (souvent JSON), utile pour certains cas spécifiques ⚠️ Moins naturel pour relations complexes / intégrité stricte Comment mettre en place une base de données (méthode propre) 1) Définir le besoin Quelles entités ? (ex : utilisateurs, articles, rôles) Quels liens ? (ex : un article appartient à une section) Quelles règles ? (email unique, statut, dates) Quelle volumétrie ? (100 lignes, 100 000, 10M ?) 2) Choisir un SGBD et un encodage standard Pour MySQL/MariaDB : préfère InnoDB (transactions + clés étrangères) et utf8mb4 (emoji/accents OK). 3) Créer la base -- MySQL / MariaDB CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 4) Créer des tables “propres” (contraintes + index) Exemple simple : users, sections, articles. -- Table utilisateurs CREATE TABLE appdb.users ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, email VARCHAR(190) NOT NULL, nom VARCHAR(120) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_users_email (email) ) ENGINE=InnoDB; -- Table sections CREATE TABLE appdb.sections ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, titre VARCHAR(140) NOT NULL, actif TINYINT(1) NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINE=InnoDB; -- Table articles (liée à users + sections) CREATE TABLE appdb.articles ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, section_id INT UNSIGNED NOT NULL, auteur_id INT UNSIGNED NOT NULL, titre VARCHAR(200) NOT NULL, contenu MEDIUMTEXT NOT NULL, statut ENUM('brouillon','publie','pause','archive') NOT NULL DEFAULT 'brouillon', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NULL, PRIMARY KEY (id), KEY idx_articles_section (section_id), KEY idx_articles_auteur (auteur_id), CONSTRAINT fk_articles_sections FOREIGN KEY (section_id) REFERENCES sections(id) ON UPDATE CASCADE ON DELETE RESTRICT, CONSTRAINT fk_articles_users FOREIGN KEY (auteur_id) REFERENCES users(id) ON UPDATE CASCADE ON DELETE RESTRICT ) ENGINE=InnoDB; ⚠️ Attention Les clés étrangères protègent l’intégrité : tu ne peux pas référencer un auteur ou une section inexistante. 5) Prévoir le minimum vital en production Sauvegardes régulières Moindre privilège (un compte applicatif limité) Logs / monitoring (au moins erreurs et espace disque)…