Une base de données qui accepte tout est une base de données qui contient des déchets. L'intégrité des données n'est pas une fonctionnalité optionnelle -- c'est le fondement dont chaque couche applicative au-dessus de la base de données dépend.
FlinDB implémente un système de contraintes déclaratif, lisible et complet. La session 161 fut le marathon qui l'a rendu réel -- neuf types de contraintes, 31 tests, et un système de cascade qui gère correctement la suppression douce et la destruction dure.
Les trois niveaux de contraintes
P1 : contraintes essentielles
Contraintes d'unicité :
``flin
entity User {
email: text @unique
username: text @unique
}
``
Contraintes required : les champs sans le suffixe ? sont requis par défaut.
Application des clés étrangères : vérifie que les entités référencées existent.
Comportement ON DELETE : cascade, restrict, set_null.
P2 : contraintes importantes
Contraintes check :
``flin
entity Product {
price: number @check(price > 0)
quantity: int @check(quantity >= 0)
}
``
Required conditionnel :
``flin
entity Order {
delivery_type: text
shipping_address: text @required_if(delivery_type == "shipping")
}
``
Validation par pattern :
``flin
entity User {
email: text @pattern(email, "^[a-zA-Z0-9+_.-]+@[a-zA-Z0-9.-]+$", "Invalid email format")
}
``
P3 : contraintes utiles
Unique partielle, unique insensible à la casse, champs immuables.
Messages d'erreur qui aident
Les messages d'erreur de FlinDB sont conçus pour être compris immédiatement :
"User with email '[email protected]' already exists"(violation d'unicité)"User requires field 'name' but it was not provided"(violation required)"Product price must satisfy: price > 0"(violation check)"Transaction field 'amount' is immutable and cannot be changed"(violation d'immuabilité)
Pourquoi les contraintes appartiennent au modèle de données
Quand les contraintes vivent dans la couche applicative, elles peuvent être contournées. Quand les contraintes sont déclaratives -- écrites comme annotations sur les champs d'entité -- elles servent à la fois de validation et de documentation.
Le système de contraintes de FlinDB n'est pas une fonctionnalité. C'est une philosophie : le modèle de données doit être complet et auto-appliqué.
Ceci est la partie 4 de la série « How We Built FlinDB ».
Navigation de la série : - [056] FlinDB: Zero-Configuration Embedded Database - [057] Entities, Not Tables - [058] CRUD Without SQL - [059] Constraints and Validation in FlinDB (vous êtes ici) - [060] Aggregations and Analytics