SQLite : créer une base de données (.db)

Une base SQLite, c'est juste un fichier

Si vous venez de MySQL ou Postgres, vous avez l'habitude de lancer CREATE DATABASE myapp; et de laisser le serveur gérer la création d'une nouvelle base quelque part en coulisses. Avec SQLite, ça ne marche pas comme ça. Pas de serveur. Pas d'instruction CREATE DATABASE. Une base de données SQLite, c'est un simple fichier sur le disque — souvent avec une extension .db, .sqlite ou .sqlite3, mais l'extension n'est qu'une convention.

Pour créer une base SQLite, il suffit de pointer l'outil sqlite3 vers un nom de fichier qui n'existe pas encore :

sqlite3 mydata.db

C'est tout. Si mydata.db n'existe pas, SQLite est prêt à le créer. S'il existe déjà, SQLite l'ouvre. Une seule et même commande dans les deux cas. Mentalement, c'est plus proche d'« ouvrir un document » que de « démarrer un serveur de base de données ».

Le fichier n'apparaît qu'au premier écrit

Voilà un détail qui en surprend plus d'un. Lancez la commande ci-dessus, tapez .quit, puis regardez dans votre dossier. Le fichier n'y est pas.

SQLite est fainéant. Il ne prend pas la peine de créer le fichier sur le disque tant qu'il n'a rien à y mettre. Dès que vous créez une table ou que vous validez des données, le fichier se matérialise :

CREATE TABLE notes (
    id INTEGER PRIMARY KEY,
    body TEXT
);

Désormais, mydata.db est bien présent sur le disque. Tant que cette première écriture n'a pas eu lieu, la « base » ne vit que dans la mémoire de la connexion. Ça surprend parfois — mais c'est aussi pratique : une session avortée ne laisse aucune trace derrière elle.

Créer une base SQLite en ligne de commande

Voici le déroulé complet depuis un terminal vierge :

$ sqlite3 mydata.db
SQLite version 3.45.0
Enter ".help" for usage hints.
sqlite> CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
sqlite> .databases
main: /home/you/mydata.db r/w
sqlite> .quit

Quelques commandes CLI bien pratiques quand vous êtes dedans :

• .databases — affiche les bases attachées avec le chemin de leur fichier.
• .tables — liste les tables de la base courante.
• .schema — montre les instructions CREATE TABLE pour tout ce qui existe.
• .quit — pour sortir.

Si vous êtes déjà dans sqlite3 sans fichier ouvert (parce que vous l'avez lancé sans argument), vous pouvez attacher un fichier avec .open :

sqlite> .open mydata.db

Même règle : il le crée s'il n'existe pas, il l'ouvre sinon.

Le « If Not Exists » est natif

Une inquiétude classique quand on vient d'autres SGBD : et si le fichier existe déjà ? Est-ce que je vais l'écraser ? Non. Ouvrir un fichier existant, ça l'ouvre, point. Rien n'est écrasé. L'équivalent le plus proche de CREATE DATABASE IF NOT EXISTS, c'est tout simplement... d'ouvrir le fichier. SQLite gère les deux cas avec la même commande.

Si vous voulez vraiment repartir de zéro, supprimez le fichier d'abord :

rm mydata.db
sqlite3 mydata.db

Mais réfléchissez-y à deux fois avant : il n'y a pas de retour en arrière possible, ni d'outil d'admin pour récupérer le fichier.

Créer une base SQLite en Python

La plupart du temps, vous ne passerez pas par la ligne de commande — vous créerez vos bases directement depuis le code de votre application. Python embarque le module sqlite3 dans sa bibliothèque standard, donc rien à installer :

-- Code Python équivalent :
-- import sqlite3
-- conn = sqlite3.connect("mydata.db")
-- conn.execute("CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT)")
-- conn.commit()
-- conn.close()

CREATE TABLE notes (
    id INTEGER PRIMARY KEY,
    body TEXT
);

sqlite3.connect("mydata.db") suit la même logique que la CLI : si le fichier n'existe pas, il est créé ; sinon, il est simplement ouvert. Tous les autres bindings (le better-sqlite3 de Node, le driver database/sql de Go, rusqlite côté Rust, etc.) fonctionnent pareil — ils enrobent tous la même bibliothèque C en dessous.

Petit raccourci propre à Python : si vous passez ":memory:" comme chemin, vous obtenez une base SQLite en mémoire, qui vit dans la RAM et disparaît à la fermeture de la connexion. On y revient sur la page suivante.

Où placer le fichier .db ?

Puisque la base est un simple fichier, la question « je le mets où ? » se pose vraiment. Quelques règles de bon sens :

• Pour une appli : dans le répertoire de données de l'utilisateur ou dans le dossier de travail de votre application. Évitez de le coller à côté de l'exécutable sur les systèmes où ce chemin n'est pas accessible en écriture.
• Pour un projet : à la racine du dépôt ou dans un dossier data/. Ajoutez-le au .gitignore s'il contient un état local — versionner une base binaire dans Git, ça finit rarement bien.
• Pour les tests : utilisez :memory: ou un fichier temporaire. C'est rapide et ça se nettoie tout seul.

Les permissions comptent aussi. L'utilisateur qui exécute le processus doit avoir les droits de lecture et d'écriture sur le fichier et sur son dossier parent (SQLite crée des fichiers de verrou à côté de la base pendant les écritures).

Un petit test pour vérifier que tout marche

Pour s'assurer que toute la chaîne fonctionne de bout en bout :

CREATE TABLE greetings (
    id INTEGER PRIMARY KEY,
    message TEXT NOT NULL
);

INSERT INTO greetings (message) VALUES ('bonjour'), ('monde');

SELECT * FROM greetings;

Vous devriez récupérer deux lignes. Si tout fonctionne, c'est que votre fichier de base de données existe, que votre schéma est en place et que vos données sont interrogeables. Et voilà, c'est tout ce qu'il y a à savoir pour « créer une base de données » avec SQLite — pas de serveur, pas d'utilisateurs, pas de table de permissions. Juste un fichier.

La suite : les bases SQLite en mémoire

Le même appel sqlite3.connect(...) qui crée un fichier peut aussi, avec le bon argument, créer une base de données qui ne touche jamais le disque. Les bases en mémoire sont la façon la plus rapide d'exécuter des tests, de prototyper un schéma ou de stocker des données temporaires. On voit ça tout de suite.