SQLite devrait avoir des éditions

Présentation de SQLite

SQLite est un moteur de base de données incroyable. Je l'utilise comme base de données pour de nombreux projets intégrés, et je ne pense pas exagérer en le qualifiant de norme industrielle pour le stockage de données locaux. Certains logiciels serveurs l'utilisent même ; par exemple, lobste.rs fonctionne maintenant sur SQLite.

Contrairement aux SGBDR (Systèmes de Gestion de Base de Données Relationnels) traditionnels, SQLite n'est pas un processus séparé ; c'est un SGBDR en tant que bibliothèque, ce qui signifie que votre logiciel reste autonome. Contrairement aux formats de fichiers traditionnels, vous n'avez pas besoin d'écrire des sérialiseurs et des analyseurs personnalisés.

Problèmes de configuration par défaut

Il y a juste un énorme problème. Ses paramètres par défaut sont tous faux. Le premier problème est que les contraintes de clé étrangère sont ignorées par défaut. Vous lisez bien. Les contraintes de clé étrangère sont probablement l'outil principal dont nous disposons pour nous assurer qu'une base de données reste cohérente et n'a pas de références pendantes.

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    display_name TEXT
);
CREATE TABLE posts (
    id INTEGER PRIMARY KEY,
    user_id INTEGER NOT NULL,
    content TEXT NOT NULL,
    FOREIGN KEY(user_id) REFERENCES users(id)
);

Le comportement typique de tous les autres SGBDR serait que la colonne user_id d'un post doit toujours référencer l'ID d'un utilisateur valide. Vous ne pouvez pas créer un nouveau post sans fournir un ID d'utilisateur valide, vous ne pouvez pas supprimer un utilisateur sans également supprimer ses posts, sinon vous obtiendrez une erreur de violation de contrainte de clé étrangère.

Problèmes de typage

Le deuxième problème est que les colonnes peuvent stocker le mauvais type de données. SQLite a un système de types simple : une valeur peut être NULL, un INTEGER, un REAL (également appelé nombre à virgule flottante double précision), du TEXT ou un BLOB (également appelé données binaires). Par conséquent, une colonne peut être définie pour contenir des valeurs de l'un de ces types.

CREATE TABLE music (
    id INTEGER PRIMARY KEY,
    name TEXT,
    duration_sec INTEGER
);
INSERT INTO music (name, duration_sec) VALUES ('Lost In Hollywood', 321);
INSERT INTO music (name, duration_sec) VALUES ('Comfortably Numb', 382);
INSERT INTO music (name, duration_sec) VALUES ('The Way of All Flesh', 'Way too long, I mean come on');

Heureusement, SQLite a le concept de tables strictes, qui fait que SQLite produit une erreur de type lorsque le mauvais type est inséré dans une colonne : CREATE TABLE music (id INTEGER PRIMARY KEY, name TEXT, duration_sec INTEGER) strict;

Conclusion

Il est évident que les paramètres par défaut de SQLite posent des problèmes importants. Les contraintes de clé étrangère et les types de données doivent être gérés avec soin pour éviter les erreurs et les incohérences dans la base de données. Les tables strictes offrent une solution pour résoudre ces problèmes, mais il est regrettable qu'il n'y ait pas de pragma pour les activer globalement.