Du JSON vers une base de données relationnelle
Une base de données peut accepter chaque insertion et vous donner malgré tout un budget d'achat erroné. Découvrez comment un prix mal placé corrompt un catalogue produits, et comment Entity Enricher transforme des décisions validées d'identité et de relations en tables et mises à jour reproductibles.
L'agent interprète votre JSON et écrit le SQL. Supabase MCP exécute ce SQL via apply_migration et execute_sql. C'est à votre agent ou à votre application de fournir les règles de modélisation, d'identité et d'imports répétés.
Vous passez en revue un schéma réutilisable, avec ses clés et ses relations partagées ou détenues par un parent. Le moteur en dérive les tables, les contraintes et les index structurels, puis livre les modifications de données suivantes via le même modèle. L'IA aide à proposer le modèle ; le code applique ses règles.
Cette comparaison porte sur un agent qui construit à partir de JSON via Supabase MCP. Une application Supabase bien conçue peut elle aussi mettre en place ces garde-fous. Le modèle défectueux ci-dessous illustre un risque de modélisation ; ce n'est ni un comportement par défaut de Supabase ni un taux d'échec mesuré.
Ce catalogue fictif contient deux échantillons de produits. Le fournisseur SUP-7 vend une lampe 12 € et un bureau 85 €. Le fournisseur est partagé ; le prix et le délai de livraison appartiennent à chaque offre.
[
{
"sku": "LAMP-01",
"name": "Reading lamp",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 12,
"lead_time_days": 3
}
]
},
{
"sku": "DESK-02",
"name": "Writing desk",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 85,
"lead_time_days": 14
}
]
}
]Dans Entity Enricher, il s'agit d'exemples de schémas, pas d'un import automatique de données. Vérifiez le schéma généré, marquez le fournisseur comme partagé et les offres comme appartenant au parent, puis publiez et enrichissez ou injectez les enregistrements correspondants. Des SKU et des ID fournisseurs stables fournissent l'identité dans cet exemple.
Mappage erroné à titre d'illustration
| Colonne et clé | Type SQL |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Colonne et clé | Type SQL |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Mettre à jour SUP-7 avec l'offre du bureau écrase le prix et le délai de livraison de la lampe. La clé étrangère est valide. Les données sont fausses. Cette structure limite aussi chaque produit à un seul fournisseur.
Entity Enricher avec le modèle validé
| Colonne et clé | Type SQL |
|---|---|
| skuPK | text |
| name | text |
| Colonne et clé | Type SQL |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Colonne et clé | Type SQL |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Une seule ligne fournisseur est réutilisée. Chaque paire produit–fournisseur a son propre prix et son propre délai de livraison. Ajouter l'offre du bureau laisse intacte celle de la lampe.
Noms de tables et clés naturelles simplifiés ; les métadonnées de synchronisation sont omises. PK = clé primaire, FK = clé étrangère. Les deux clés d'offre forment une seule clé composite. Cet exemple suppose une seule offre courante par paire ; les historiques de prix, les devises ou les paliers de quantité nécessitent une modélisation supplémentaire.
Un acheteur a besoin de 100 lampes. Basculez entre le premier et le second import pour voir ce que renvoie chaque modèle.
Modèle erroné : budget pour 100 lampes
8 500 €
Surévalué de 7 300 €. Votre rapport de marge et vos prévisions d'achat utilisent désormais le prix du bureau.
Modèle EE revu : budget pour 100 lampes
1 200 €
L'offre de la lampe reste à 12 € avec un délai de livraison de 3 jours. L'offre du bureau occupe une ligne distincte.
Calcul illustratif à partir des données d'exemple ; aucun appel à une base de données ni perte financière mesurée.
Générez un nouvel ID fournisseur à chaque import et les achats se répartissent entre des profils en double. Les totaux de dépenses et les comparaisons entre fournisseurs deviennent trompeurs.
Entity Enricher
Les clés stables déclarées font converger les entités répétées. Les ID sémantiques optionnels peuvent aider lorsque les libellés varient, avec des correspondances qui restent à valider.
Une clé de jonction commençant par product_sku ne remplace pas un index commençant par supplier_id. Les recherches inverses peuvent devenir coûteuses à mesure que votre catalogue grandit.
Entity Enricher
EE génère des index structurels pour ses relations, y compris les recherches de jonction inverses, et évite les index redondants à préfixe de tête. Ajustez les autres index à vos requêtes réelles.
Votre JSON gagne un champ d'offre, mais pas la table cible ni le SQL d'import. Les nouvelles données ne se chargent pas ou n'atteignent jamais les rapports qui en ont besoin.
Entity Enricher
Le schéma publié détermine à la fois la forme des tables et la projection des données. Prévisualisez les migrations prises en charge avant de publier ; les transformations non prises en charge sont bloquées.
Une connexion tombe après un import. Sans règles de rejeu, une nouvelle tentative peut créer des doublons ; une mise à jour plus ancienne peut remplacer une offre plus récente.
Entity Enricher
EE fournit une livraison ordonnée, des upserts basés sur l'identité et des garde-fous de révision. Le client PostgreSQL applique un traitement par lot dans une transaction et l'acquitte après le commit.
Le modèle renvoie du JSON, mais une offre n'a pas de clé requise ou la cible refuse l'écriture. Un simple message de succès peut masquer des produits et des offres manquants.
Entity Enricher
Les politiques d'admission peuvent rejeter une entité ou omettre des enfants incomplets. EE signale les résultats partiels et suit séparément la livraison aux réplicas, ce qui vous permet d'identifier ce qui doit être corrigé.
Réécrire des offres inchangées consomme des ressources de base de données, maintient inutilement les index et rend plus bruyant le traitement des changements en aval.
Entity Enricher
EE détecte l'état inchangé d'une entité et protège les mises à jour de lignes contre les valeurs inchangées. Les consommateurs peuvent suivre le flux de deltas pour les changements, y compris les suppressions.
Passez en revue l'identité, la propriété et la signification de chaque champ avant de publier. EE rend ces décisions exécutables ; il ne peut pas prouver que votre modèle métier est correct. La correspondance sémantique peut se tromper, et les performances des requêtes dépendent toujours de la charge de travail et de la taille de la base de données.
Le dernier enrichissement remplace l'état courant : des valeurs manquantes peuvent effacer les valeurs précédentes, et une liste d'offres détenues plus courte supprime les offres omises. Conservez un historique séparé si nécessaire. Des données partielles ou rejetées exigent une correction et un renvoi ; un statut de livraison ne constitue pas une réparation automatique.
Supabase MCP est utile lorsque vous voulez qu'un agent inspecte une base de données et écrive du SQL sur mesure. EE est utile lorsque le même contrat de données doit continuer à produire des mises à jour relationnelles cohérentes. Vous pouvez utiliser Supabase PostgreSQL comme destination du client de synchronisation d'EE, sous réserve des autorisations de connexion et de base de données. La configuration des politiques d'accès applicatives reste à votre charge.
Revu le 10 septembre 2026. Supabase fournit des migrations et des Advisors qui signalent les index manquants ; la particularité d'EE est de générer et d'appliquer des règles à partir du schéma d'enrichissement revu.