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)
• Migrations (évolution du schéma proprement)

…