Base De Données on Dev TLDRLSS

Ne vous laissez pas tromper par la désinvolture de SQLite ! Quels sont les pièges des types dynamiques ? Pourquoi ALTER TABLE est-il à moitié opérationnel ? Comment construire une architecture de programmation défensive en Node.js pour des mises à niveau de schéma sans douleur ?

Tue, 19 May 2026 18:10:00 +0800

Imaginez un bac de recyclage sur lequel vous avez clairement apposé une étiquette indiquant "Bouteilles en plastique uniquement", mais lorsque quelqu’un y jette un morceau de papier, il l’accepte silencieusement sans un seul mot de protestation ?

C’est l’expérience effrayante que vivent les développeurs lorsqu’ils découvrent le système de types de SQLite pour la première fois.

Si vous êtes habitué au style rigide d’agent des douanes de PostgreSQL (où les types incorrects sont directement rejetés), la désinvolture de SQLite pourrait vous faire douter de votre vie.

Encore plus effrayant, lorsque vous souhaitez modifier la structure d’une table, il vous dira :

"La table ne peut pas être modifiée directement. Veuillez construire une nouvelle maison, y déménager les meubles, puis faire sauter l’ancienne maison."

Sous le capot, SQLite ne possède que 5 classes de stockage

Peu importe les noms de types élégants que vous déclarez dans CREATE TABLE (VARCHAR(255), BIGINT, DECIMAL), SQLite sous le capot ne reconnaît que ces 5 classes de stockage :

Classe de stockage	Description
NULL	Valeur nulle
INTEGER	Entier (occupe automatiquement 1 à 8 octets selon l’importance de la valeur)
REAL	Nombre à virgule flottante (fixé à 8 octets)
TEXT	Chaîne de caractères (encodage UTF-8 par défaut)
BLOB	Grand objet binaire (stocké exactement comme saisi)

Les types que vous définissez sur les colonnes sont simplement des "suggestions" pour SQLite, pas des "règles obligatoires".

C’est ce qu’on appelle la "Type Affinity" (Affinité de types). SQLite tentera de convertir vos données vers le type suggéré, mais s’il ne le peut pas, il insérera simplement les données d’origine sans générer d’erreur.

Vous pouvez déclarer une colonne age INTEGER dans SQLite puis y insérer la chaîne 'toujours dix-huit ans'; il l’acceptera volontiers.

Trois pièges de types les plus faciles à commettre

Piège 1 : Pas de Boolean nativo

SQLite n’a pas de type booléen. True et False ne peuvent être représentés que par les entiers 1 et 0.

Lorsque vous récupérez des données de SQLite à l’aide de Node.js, vous obtiendrez le nombre 1 ou 0, pas true ou false.

Si vous effectuez directement une vérification telle que if (user.is_admin === true), elle ne sera jamais vraie.

Piège 2 : Pas de type Date/Time

SQLite n’a pas de type date/heure. Vous ne pouvez stocker le temps que sous forme de :

Méthode de stockage	Exemple	Avantages & Inconvénients
TEXT (chaîne ISO-8601)	`'2026-05-19T18:00:00Z'`	Le plus recommandé, grande lisibilité, conversion parfaite lors du passage à PostgreSQL à l’avenir
INTEGER (Unix Timestamp)	`1747656000`	Faible encombrement, mais illisible pour l’homme

Ne stockez jamais de dates dans des formats personnalisés arbitraires comme 19/05/2026 18:00, sinon la future migration de données sera une catastrophe.

Piège 3 : Insérer une chaîne dans une colonne Integer ne générera pas d’erreur

Dans PostgreSQL, insérer une chaîne dans une colonne INTEGER génère une erreur immédiatement. Mais SQLite essaiera seulement de la convertir silencieusement, et en cas d’échec, l’acceptera telle quelle.

Cela signifie que des données sales peuvent s’infiltrer silencieusement dans votre base de données jusqu’à ce qu’un jour votre programme plante en raison de la réception d’un type inattendu, ce n’est qu’alors que vous découvrirez le problème.

Programmation défensive : Traiter une base de données désinvolte avec une attitude stricte

Face à la désinvolture de SQLite, vous devez construire des mécanismes de défense stricts dans le développement avec Node.js :

Niveau de défense	Outil	Rôle
Garde au compile-time	TypeScript	Capturer les types incorrects à l’étape d’écriture du code
Validation d’entrée d’API	Zod	Valider les données entrantes strictement (s’assurer que age est toujours un nombre)
Conversion implicite de types	Prisma / Drizzle ORM	Gérer automatiquement les différences de types entre SQLite et PostgreSQL

Déplacer le "videur de validation de données" de la couche base de données vers la couche application Node.js est une stratégie clé pour tirer parti de la rapidité de développement de SQLite tout en garantissant l’évolutivité future.

Lors de l’utilisation d’un ORM, tant que vous déclarez type: 'boolean' dans votre code, l’ORM le convertit automatiquement en 1/0 lors de la sauvegarde dans SQLite, et le reconvertit en true/false lors de la lecture, masquant parfaitement les différences de types sous-jacentes.

ALTER TABLE est à moitié opérationnel : Ce qui peut et ne peut pas être modifié

Le support de SQLite pour la modification des structures de tables est très limité :

Opération	Pris en charge
Ajouter une colonne (`ADD COLUMN`)	Oui
Renommer une colonne (`RENAME COLUMN`)	Oui
Supprimer une colonne (`DROP COLUMN`)	Oui (dans les versions plus récentes)
Renommer une table (`RENAME TO`)	Oui
Modifier le type d’une colonne	Non
Ajouter/supprimer les contraintes `UNIQUE`, `NOT NULL`	Non
Modifier la clé primaire	Non
Modifier la clé étrangère	Non

Une fois que vous devez effectuer l’une des modifications "non prises en charge", SQLite exige que vous exécutiez la stratégie de "recréer et déplacer".

Les quatre étapes pour recriar et déplacer : La façon de mettre à niveau les tables de SQLite

Comme cela ne peut pas être modifié directement, la pratique standard recommandée par les documents officiels est de construire une nouvelle maison, d’y déménager les meubles, de faire sauter l’ancienne maison et d’apposer la nouvelle plaque nominative :

Étape	Action	Description
1	Créer une nouvelle table	`CREATE TABLE users_new (...)` en utilisant la structure correcte
2	Copier les données	`INSERT INTO users_new SELECT ... FROM users`
3	Supprimer l’ancienne table	`DROP TABLE users`
4	Renommer la table	`ALTER TABLE users_new RENAME TO users`

Ces quatre étapes doivent être exécutées d’une seule traite; toute coupure de courant ou crash d’application à mi-chemin entraînera la perte de données.

Garantir que les mises à niveau ne perdent pas de données : Deux lignes de défense de sécurité

Ligne de défense 1 : Défense physique, copier le fichier directement

SQLite est essentiellement un simple fichier. Avant d’exécuter des modifications de schéma, copiez simplement le fichier .db en tant que sauvegarde.

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

Si les choses tournent mal, le remplacement du fichier restaure tout en un clin d’œil. C’est un avantage que d’autres grandes bases de données ne peuvent pas offrir.

Ligne de défense 2: Enveloppe de Transaction, la machine à remonter le temps de la base de données

Enveloppez toutes les étapes de migration dans une seule Transaction; si une étape échoue, tout le processus sera automatiquement annulé (Rollback) comme si rien ne s’était passé.

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('Table mise à niveau avec succès');
} catch (error) {
  console.error('La mise à niveau a échoué, données restaurées en toute sécurité :', error.message);
}

"Fichier de sauvegarde + Liaison par Transaction" constitue l’airbag de la migration de votre base de données.

Contrôlez la désinvolture de SQLite avec une attitude stricte

Domptez la désinvolture de SQLite avec une architecture stricte de couche d’application pour profiter de sa vitesse de développement ultrarapide tout en évitant les dettes techniques futures.

Le système de types de SQLite est très désinvolte, et ALTER TABLE présente de nombreuses limitations.

Cependant, tant que vous effectuez la vérification des types TypeScript + validation Zod + l’abstraction ORM du côté de Node.js, combinées à la stratégie de sécurité de sauvegarde physique + Transaction, vous pouvez profiter en toute sécurité de l’efficacité de développement offerte par SQLite tout en ouvrant la voie à une migration aisée vers PostgreSQL à l’avenir.

Reference

N'utilisez pas PostgreSQL pour tout ! Quels sont les avantages de l'architecture embarquée et de la configuration zéro de SQLite ? Où sont les limites de SQLite ? Quand devriez-vous choisir SQLite et quand PostgreSQL ?

Tue, 19 May 2026 18:00:00 +0800

Avez-vous déjà pensé au fait que le navigateur que vous ouvrez chaque jour, le logiciel de communication sur votre téléphone et même l’outil de prise de notes sur votre bureau cachent tous cette même base de données légère ?

Elle ne nécessite l’installation d’aucun logiciel serveur, ne requiert aucune configuration de compte ou de mot de passe, et n’a même pas besoin d’une connexion Internet. C’est simplement un fichier, qui repose tranquillement sur votre disque dur, prêt à vous servir à tout moment.

Cette existence discrète, c’est SQLite.

Qu’est-ce que SQLite ? La base de données la plus déployée au monde

SQLite est un moteur de base de données relationnelle embarqué écrit en C.

Il n’a pas de processus serveur indépendant, mais est directement embarqué dans votre application pour s’exécuter.

C’est complètement différent de PostgreSQL ou MySQL avec lesquels vous êtes familier. Les bases de données traditionnelles sont des serveurs indépendants qui s’exécutent séparément, et votre programme doit “communiquer” avec eux via un protocole réseau (TCP/IP).

But SQLite est différent ; c’est simplement un bloc de code, s’exécutant directement au sein de votre application, lisant et écrivant ce fichier .db sur votre disque dur.

Dimension de comparaison	SQLite (Embarqué)	PostgreSQL (Client-Serveur)
Mode de fonctionnement	Directement embarqué dans l’application, pas de serveur indépendant	Processus serveur indépendant, via connexion réseau
Configuration	Configuration zéro, pas d’installation, pas d’identifiants	Requiert installation, configuration compte/mot de passe & pare-feu
Stockage des données	Fichier unique multiplateforme	Multiples fichiers sous le répertoire du serveur
Méthode de sauvegarde	Copier directement ce fichier	Requiert des outils dédiés comme pg_dump

C’est précisément en raison de cette caractéristique “plug-and-play” que SQLite est devenu le moteur de base de données le plus déployé au monde.

Des systèmes d’exploitation Android et iOS, aux navigateurs Chrome et Firefox, en passant par Adobe Lightroom, WhatsApp et même le système de vol de l’Airbus A350, il est partout.

Utiliser SQLite dans Node.js

Si vous êtes un développeur Node.js, utiliser SQLite est extrêmement simple. Vous n’avez pas besoin d’installer de logiciel de serveur de base de données sur votre ordinateur, il vous suffit d’installer un paquet npm pour commencer.

Les options les plus couramment utilisées dans l’industrie aujourd’hui :

Nom du paquet	Caractéristiques	Scénario recommandé
`sqlite3`	Le plus établi, prend en charge les API asynchrones	Lorsqu’il faut gérer de nombreuses tâches asynchrones en parallèle
`better-sqlite3`	Excellentes performances, conception d’API intuitive, extrêmement rapide	Recommandation principale, pour l’efficacité du développement et la vitesse d’exécution

Créer une base de données et l’interroger avec better-sqlite3 prend moins de cinq minutes :

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

Si le fichier n’existe pas, better-sqlite3 le créera automatiquement pour vous.

SQLite prend en charge une syntaxe SQL plus puissante que vous ne le pensez

Beaucoup de gens pensent que SQLite est très basique, mais il prend en charge la grande majorité de la syntaxe SQL standard, y compris de nombreuses fonctionnalités avancées :

Catégorie de syntaxe	Éléments pris en charge
Opérations de base	`SELECT`, `INSERT`, `UPDATE`, `DELETE`
Définition des données	`CREATE TABLE`, `CREATE INDEX`, `CREATE VIEW`
Requêtes avancées	`WITH` (CTEs récursives), Fonctions de fenêtre (Window Functions)
Gestion des conflits	`UPSERT` (`INSERT ... ON CONFLICT DO UPDATE`)
Traitement du JSON	Fonctions intégrées comme `json_extract`, `json_array`, `json_object`, etc.
Contrôle des transactions	`BEGIN`, `COMMIT`, `ROLLBACK`, `SAVEPOINT`
Requêtes de jointure	`INNER JOIN`, `LEFT JOIN`, `RIGHT JOIN` et `FULL OUTER JOIN`

La philosophie centrale de SQLite est “petit et beau”, prenant en charge la plupart des capacités SQL dont vous avez besoin au quotidien tout en restant extrêmement léger.

Où sont les limites de SQLite ?

La légèreté a un prix. Si l’on compare SQLite à une épicerie hipster avec une seule caisse, alors PostgreSQL est un Costco équipé de 50 caisses.

1. Embouteillage d’écriture

Lorsque SQLite écrit des données, il verrouille l’intégralité du fichier de base de données.

Imaginez un restaurant avec une seule toilette : 100 personnes peuvent regarder le menu à l’extérieur (lire) en même temps, mais tant qu’une personne y entre et verrouille la porte (écrire), toutes les autres ne peuvent que faire la queue et attendre.

Bien que l’activation du mode WAL (Write-Ahead Logging) puisse améliorer les performances de lecture/écriture simultanées, il reste fondamentalement impossible d’effectuer des écritures simultanées multi-thread sur différentes lignes de données.

2. Impossible de s’étendre sur plusieurs serveurs

L’essence de SQLite est un fichier physique. Si votre système est déployé sur plusieurs serveurs (mise à l’échelle horizontale), ces serveurs ne peuvent pas partager le même fichier en toute sécurité.

3. Manque de gestion des permissions détaillée

SQLite n’a pas de concept de “comptes d’utilisateurs”. Quiconque peut lire ce fichier .db au niveau du système d’exploitation peut voir et modifier toutes les données.

Pour les systèmes d’entreprise qui nécessitent des audits stricts des données personnelles, c’est inacceptable.

SQLite vs. PostgreSQL : Décisions de sélection technologique

Les outils ne sont ni bons ni mauvais, ils sont seulement adaptés ou non. Voici une liste de contrôle ultime pour vous aider à prendre une décision :

Question	Réponse “Oui” → Choisissez SQLite	Réponse “Non” → Choisissez PostgreSQL
Y a-t-il un seul serveur backend, ou s’exécute-t-il entièrement en local ?	Oui	Non (requiert une mise à l’échelle horizontale, plusieurs machines)
Le comportement du système est-il dominé par la lecture, sans écritures simultanées fréquentes ?	Oui	Non (les utilisateurs se disputeront l’écriture simultanée)
Pas besoin de permissions de compte de base de données détaillées ni d’indexation avancée ?	Oui	Non (dépend fortement de fonctionnalités avancées)

Comparations de scénarios plus spécifiques :

Scénario	Sélection recommandée	Raison
Logiciels de bureau, Applications mobiles, Appareils IoT	SQLite	Les données voyagent avec l’appareil, pas d’installation
Blogs personnels, Sites vitrines	SQLite	Beaucoup de lecture, peu d’écriture, économise les coûts du serveur
Développement rapide de prototypes, Demos	SQLite	Créez simplement un fichier pour commencer
Forums communautaires, Plateformes d’e-commerce	PostgreSQL	Forte simultanéité d’écriture, requiert un verrouillage au niveau de la ligne
Déploiement distribué sur plusieurs serveurs	PostgreSQL	Nécessité de partager la source de données entre différentes machines
Systèmes sensibles comme le médical ou la finance	PostgreSQL	Requiert un contrôle strict des permissions basé sur les rôles

Votre base de données est-elle un bloc-notes de poche ou un standard téléphonique central ?

Si les données sont de type “monoposte, statiques, propriétaire unique”, choisissez SQLite pour profiter d’une légèreté et d’une liberté extrêmes ;

Si les données sont de type “cloud, dynamiques, hautement interactives”, laissez PostgreSQL prendre le relais.

La philosophie centrale de SQLite est “un composant interne de l’application”, tandis que PostgreSQL est positionné comme “un centre indépendant de l’architecture du système”.

La prochaine fois que vous prendrez une décision d’architecture, ne vous précipitez pas pour sortir PostgreSQL. Demandez-vous d’abord :

“Ma base de données est-elle un bloc-notes de poche, ou un standard téléphonique central ?”

Une fois la réponse claire, le choix s’impose naturellement.