Le modèle relationnel domine le stockage de données depuis cinquante ans. Tables, lignes, colonnes, clés étrangères, jointures. C'est une abstraction puissante -- et une terrible correspondance avec la façon dont les développeurs pensent réellement à leurs applications.
FlinDB élimine entièrement la traduction. Vous pensez en entités. Vous écrivez en entités. FlinDB stocke des entités. Il n'y a pas de décalage d'impédance parce qu'il n'y a pas de décalage.
La différence fondamentale
Dans SQL, vous définissez une table -- un conteneur pour des lignes. Dans FLIN, vous définissez une entité -- un concept de première classe dans le langage :
flinentity User {
name: text
email: text @unique
age: int?
}Quand vous sauvegardez une entité dans FlinDB, vous obtenez un objet avec un cycle de vie riche :
flinuser = User { name: "Thales", email: "[email protected]" }
save user
user.id // 1 (auto-assigned)
user.created_at // 2026-01-13T10:00:00Z
user.version // 1
user.name = "Juste Thales"
save user
user.version // 2
user.history // [version 1, version 2]
user @ -1 // The previous versionUne entité n'est pas une ligne. C'est un objet versionné, horodaté, historiquement conscient, avec une identité qui persiste à travers les changements.
Types de champs : sémantiques, pas mécaniques
Les types de champs SQL décrivent des formats de stockage. Les types de champs FLIN sont sémantiques -- ils décrivent ce que les données sont, pas comment elles sont stockées.
| Type | Description | Exemple |
|---|---|---|
text | Chaîne UTF-8 | "Hello" |
int | Entier 64 bits | 42 |
number | Flottant 64 bits | 3.14 |
bool | Booléen | true |
time | Horodatage UTC | now |
money | Valeur monétaire | 1000 CFA |
file | Référence de fichier | Fichier uploadé |
semantic text | Texte avec embeddings IA | Contenu recherchable par IA |
Le type semantic text est particulièrement frappant. Dans SQL, si vous voulez une recherche sémantique alimentée par l'IA, vous devez installer une extension vectorielle, configurer un pipeline d'embedding, gérer des index vectoriels et écrire des requêtes de similarité. Dans FLIN, vous écrivez :
flinentity Product {
name: text
description: semantic text
}Relations : des références, pas des clés étrangères
flinentity Post {
title: text
body: text
author: User // Direct reference to a User entity
}
post.author // Returns the full User entity, not an ID
post.author.name // "Thales"Pas de jointures. Pas de clauses ON. Vous référencez une entité, et la référence fonctionne.
Plusieurs-à-plusieurs sans tables de jonction
flinentity Post {
title: text
tags: [Tag] // List of Tag references
}Pas de table de jonction. Pas de requête de jointure. Pas de problème N+1 à résoudre.
Le modèle d'historique des versions
La différence la plus fondamentale entre FlinDB et une base de données relationnelle est le versionnage temporel. Dans SQL, un UPDATE détruit la valeur précédente. Dans FlinDB, chaque sauvegarde crée une nouvelle version :
flinuser = User { name: "Juste" }
save user // Version 1
user.name = "Juste G."
save user // Version 2
user @ -1 // Version 1: "Juste"
user.history // All versionsCe n'est pas une fonctionnalité boulonnée sur un modèle relationnel. C'est le modèle de stockage lui-même.
Pourquoi la conception centrée sur les entités est importante
La conception centrée sur les entités est particulièrement puissante pour le public que FLIN sert. Les étudiants à Abidjan, Dakar et Lagos qui apprennent à coder pour la première fois n'ont pas besoin d'apprendre SQL, les ORM, les migrations et les contraintes de clés étrangères avant de pouvoir construire leur première application. Ils définissent des entités, les sauvegardent et les interrogent. La base de données disparaît derrière le langage.
Ceci est la partie 2 de la série « How We Built FlinDB ».
Navigation de la série : - [056] FlinDB: Zero-Configuration Embedded Database - [057] Entities, Not Tables: How FlinDB Thinks About Data (vous êtes ici) - [058] CRUD Without SQL - [059] Constraints and Validation in FlinDB - [060] Aggregations and Analytics