Des entités, pas des tables : comment FlinDB pense les données

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 version

Une 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.

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 versions

Ce 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