JSON naar een relationele database
Een database kan elke insert accepteren en je toch een verkeerd inkoopbudget geven. Zie hoe een verkeerd geplaatste prijs een productcatalogus corrumpeert, en hoe Entity Enricher beoordeelde beslissingen over identiteit en relaties omzet in herhaalbare tabellen en updates.
De agent interpreteert je JSON en schrijft SQL. Supabase MCP voert die SQL uit via apply_migration en execute_sql. Je agent of applicatie moet zelf de regels voor modellering, identiteit en herhaalde imports aanleveren.
Je controleert een herbruikbaar schema, inclusief sleutels en gedeelde of door de parent bezeten relaties. De engine leidt daaruit tabellen, constraints en structurele indexen af en levert latere datawijzigingen vervolgens via hetzelfde model. AI helpt het model voor te stellen; code past de regels toe.
Deze vergelijking gaat over een agent die vanuit JSON bouwt via Supabase MCP. Een goed ontworpen Supabase-applicatie kan deze waarborgen ook implementeren. Het foutieve model hieronder is een illustratie van een modelleringsrisico, geen standaardgedrag van Supabase of een gemeten foutpercentage.
Deze fictieve catalogus bevat twee productvoorbeelden. Leverancier SUP-7 verkoopt een lamp voor € 12 en een bureau voor € 85. De leverancier is gedeeld; de prijs en levertijd horen bij elke aanbieding afzonderlijk.
[
{
"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
}
]
}
]In Entity Enricher zijn dit schemavoorbeelden, geen automatische data-import. Beoordeel het gegenereerde schema, markeer de leverancier als gedeeld en de aanbiedingen als eigendom van de parent, publiceer vervolgens en verrijk of injecteer overeenkomende records. Stabiele SKU- en leveranciers-ID's leveren de identiteit voor dit voorbeeld.
Illustratieve foutieve mapping
| Kolom en sleutel | SQL-type |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Kolom en sleutel | SQL-type |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Als je SUP-7 bijwerkt met de aanbieding voor het bureau, overschrijf je de prijs en levertijd van de lamp. De refererende sleutel is geldig. De data is fout. Deze opzet beperkt elk product ook tot één leverancier.
Entity Enricher met het beoordeelde model
| Kolom en sleutel | SQL-type |
|---|---|
| skuPK | text |
| name | text |
| Kolom en sleutel | SQL-type |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Kolom en sleutel | SQL-type |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Eén leveranciersrij wordt hergebruikt. Elk product-leverancierpaar heeft zijn eigen prijs en levertijd. Het toevoegen van de aanbieding voor het bureau laat de aanbieding voor de lamp intact.
Vereenvoudigde tabelnamen en natuurlijke sleutels; sync-metadata is weggelaten. PK = primaire sleutel, FK = refererende sleutel. De twee aanbiedingssleutels vormen samen één samengestelde sleutel. Dit voorbeeld gaat uit van één actuele aanbieding per paar; prijshistorie, valuta's of staffelprijzen vragen extra modellering.
Een inkoper heeft 100 lampen nodig. Wissel tussen de eerste en tweede import om te zien wat elk model teruggeeft.
Foutief model: budget voor 100 lampen
€ 8.500
€ 7.300 te hoog ingeschat. Je margerapport en inkoopprognose gebruiken nu de prijs van het bureau.
Gecontroleerd EE-model: budget voor 100 lampen
€ 1.200
De aanbieding voor de lamp blijft € 12 met een levertijd van 3 dagen. De aanbieding voor het bureau is een aparte rij.
Illustratieve berekening op basis van de voorbeelddata; geen databasecalls of gemeten financiële verliezen.
Genereer bij elke import een nieuw leveranciers-ID en je aankopen raken verspreid over dubbele profielen. Totale uitgaven en leveranciersvergelijkingen worden misleidend.
Entity Enricher
Gedeclareerde stabiele sleutels zorgen ervoor dat herhaalde entiteiten samenvallen. Optionele semantische ID's kunnen helpen wanneer labels variëren, met matches die nog steeds beoordeling vragen.
Een junction-sleutel die begint met product_sku vervangt geen index die begint met supplier_id. Omgekeerde lookups kunnen duur worden naarmate je catalogus groeit.
Entity Enricher
EE genereert structurele indexen voor zijn relaties, inclusief omgekeerde junction-lookups, en vermijdt overbodige indexen met hetzelfde beginprefix. Stem andere indexen af op je daadwerkelijke queries.
Je JSON krijgt een nieuw veld voor aanbiedingen, maar de doeltabel of de import-SQL niet. Nieuwe data wordt niet geladen of komt nooit aan in de rapporten die het nodig hebben.
Entity Enricher
Het gepubliceerde schema bepaalt zowel de vorm van de tabellen als de projectie van de data. Bekijk vooraf welke migraties worden ondersteund voordat je publiceert; niet-ondersteunde transformaties worden geblokkeerd.
Een verbinding valt weg na een import. Zonder replay-regels kan een nieuwe poging duplicaten opleveren; een oudere update kan een recentere aanbieding vervangen.
Entity Enricher
EE zorgt voor geordende levering, identiteitsgebaseerde upserts en revisiebewaking. De PostgreSQL-client past een batch toe in een transactie en bevestigt na de commit.
Het model retourneert JSON, maar bij een aanbieding ontbreekt een vereiste sleutel of de bestemming weigert de schrijfactie. Een melding dat het gelukt is, kan ontbrekende producten en aanbiedingen verbergen.
Entity Enricher
Toelatingsregels kunnen een entiteit weigeren of onvolledige onderliggende items weglaten. EE rapporteert gedeeltelijke resultaten en volgt de levering aan replica's apart, zodat je kunt bepalen wat hersteld moet worden.
Het opnieuw wegschrijven van onveranderde aanbiedingen kost databasecapaciteit, houdt indexen onnodig bij en maakt de verwerking van wijzigingen verderop in de keten rommeliger.
Entity Enricher
EE detecteert ongewijzigde entiteitsstatus en beschermt rij-updates tegen ongewijzigde waarden. Afnemers kunnen de delta-feed volgen voor wijzigingen, inclusief verwijderingen.
Controleer identiteit, eigenaarschap en de betekenis van elk veld voordat je publiceert. EE maakt die beslissingen uitvoerbaar; het kan niet bewijzen dat je bedrijfsmodel juist is. Semantische matching kan fouten maken en queryprestaties blijven afhankelijk van je workload en de grootte van je database.
De laatste verrijking vervangt de huidige status: ontbrekende waarden kunnen eerdere waarden wissen en een kortere lijst met onderliggende aanbiedingen verwijdert de weggelaten aanbiedingen. Houd waar nodig een aparte historie bij. Gedeeltelijke of afgewezen data moet je corrigeren en opnieuw aanbieden; een leveringsstatus is geen automatisch herstel.
Supabase MCP is nuttig als je wilt dat een agent een database inspecteert en eigen SQL schrijft. EE is nuttig als hetzelfde datacontract steeds consistente relationele updates moet blijven opleveren. Je kunt Supabase PostgreSQL gebruiken als bestemming voor de sync-client van EE, afhankelijk van de verbindings- en databaserechten. Het instellen van toegangsbeleid voor je applicatie blijft jouw taak.
Gecontroleerd op 10 september 2026. Supabase biedt migraties en Advisors die ontbrekende indexen signaleren; het onderscheidende van EE is dat het regels genereert en toepast op basis van het gecontroleerde verrijkingsschema.