Concevez vos propres tables avec des types adaptés et des contraintes NOT NULL, UNIQUE et PRIMARY KEY qui protègent vos données.
Ouvrir cette leçon dans KodokonJusqu'ici vous interrogiez des tables toutes prêtes ; un développeur professionnel les conçoit. Un bon schéma refuse les données invalides au moment de l'insertion : c'est votre première ligne de défense, avant tout code applicatif. Dans sqliteonline.com ou sqlite3, créez cette table :
CREATE TABLE users (
id INTEGER PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
username TEXT NOT NULL UNIQUE,
created_at TEXT NOT NULL
DEFAULT (datetime('now'))
);SQLite ne connaît que cinq types de stockage : INTEGER, REAL, TEXT, BLOB et NULL. Les dates s'y stockent en TEXT au format ISO (2026-07-04). Ailleurs (PostgreSQL, MySQL), vous déclareriez plutôt VARCHAR(255), TIMESTAMP ou BOOLEAN : le principe reste identique, seuls les noms de types changent. Testez maintenant vos contraintes :
INSERT INTO users (email, username)
VALUES ('alice@example.com', 'alice');
INSERT INTO users (email, username)
VALUES ('alice@example.com', 'alice2');La clé primaire identifie chaque ligne : jamais NULL, jamais dupliquée, une seule par table. En SQLite, INTEGER PRIMARY KEY a une particularité précieuse : la colonne s'auto-incrémente quand vous omettez sa valeur, comme dans les insertions ci-dessus. Sur PostgreSQL vous écririez GENERATED ALWAYS AS IDENTITY, sur MySQL AUTO_INCREMENT. Ajoutez enfin une règle métier avec CHECK :
CREATE TABLE products (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
sku TEXT NOT NULL UNIQUE,
price REAL NOT NULL CHECK (price >= 0)
);
INSERT INTO products (name, sku, price)
VALUES ('Clavier', 'KB-01', -5);