JSON in eine relationale Datenbank
Eine Datenbank kann jeden Insert akzeptieren und Ihnen trotzdem das falsche Einkaufsbudget liefern. Sehen Sie, wie ein falsch zugeordneter Preis einen Produktkatalog verfälscht und wie Entity Enricher geprüfte Identitäts- und Beziehungsentscheidungen in wiederholbare Tabellen und Aktualisierungen überführt.
Der Agent interpretiert Ihr JSON und schreibt SQL. Supabase MCP führt dieses SQL über apply_migration und execute_sql aus. Die Regeln für Modellierung, Identität und wiederholte Importe müssen von Ihrem Agenten oder Ihrer Anwendung stammen.
Sie prüfen ein wiederverwendbares Schema, einschließlich Schlüsseln sowie gemeinsam genutzten oder vom übergeordneten Datensatz gehaltenen Beziehungen. Die Engine leitet daraus Tabellen, Constraints und strukturelle Indizes ab und liefert spätere Datenänderungen über dasselbe Modell aus. KI hilft beim Vorschlagen des Modells; der Code setzt dessen Regeln um.
Dieser Vergleich betrachtet einen Agenten, der über Supabase MCP aus JSON aufbaut. Eine gut entworfene Supabase-Anwendung kann diese Schutzmechanismen ebenfalls umsetzen. Das fehlerhafte Modell unten veranschaulicht ein Modellierungsrisiko und ist weder ein Supabase-Standard noch eine gemessene Fehlerrate.
Dieser fiktive Katalog enthält zwei Produktbeispiele. Lieferant SUP-7 verkauft eine Lampe für 12 € und einen Schreibtisch für 85 €. Der Lieferant ist gemeinsam genutzt; Preis und Lieferzeit gehören zum jeweiligen Angebot.
[
{
"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 sind dies Schema-Beispiele, kein automatischer Datenimport. Prüfen Sie das generierte Schema, markieren Sie den Lieferanten als gemeinsam genutzt und die Angebote als dem Parent zugehörig, veröffentlichen Sie es und reichern Sie passende Datensätze an oder fügen Sie sie ein. Stabile SKU- und Lieferanten-IDs liefern die Identität für dieses Beispiel.
Beispielhafte fehlerhafte Zuordnung
| Spalte und Schlüssel | SQL-Typ |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Spalte und Schlüssel | SQL-Typ |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Wird SUP-7 mit dem Angebot für den Schreibtisch aktualisiert, überschreibt das Preis und Lieferzeit der Lampe. Der Fremdschlüssel ist gültig. Die Daten sind falsch. Dieses Layout beschränkt jedes Produkt zudem auf einen Lieferanten.
Entity Enricher mit dem geprüften Modell
| Spalte und Schlüssel | SQL-Typ |
|---|---|
| skuPK | text |
| name | text |
| Spalte und Schlüssel | SQL-Typ |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Spalte und Schlüssel | SQL-Typ |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Eine Lieferantenzeile wird wiederverwendet. Jedes Produkt-Lieferanten-Paar hat einen eigenen Preis und eine eigene Lieferzeit. Das Hinzufügen des Angebots für den Schreibtisch lässt das Angebot für die Lampe unverändert.
Vereinfachte Tabellennamen und natürliche Schlüssel; Sync-Metadaten sind weggelassen. PK = Primärschlüssel, FK = Fremdschlüssel. Die beiden Angebotsschlüssel bilden einen zusammengesetzten Schlüssel. Dieses Beispiel geht von einem aktuellen Angebot je Paar aus; Preishistorien, Währungen oder Mengenstaffeln erfordern eine zusätzliche Modellierung.
Ein Einkäufer benötigt 100 Lampen. Wechseln Sie zwischen dem ersten und dem zweiten Import, um zu sehen, was jedes Modell zurückgibt.
Fehlerhaftes Modell: Budget für 100 Lampen
8.500 €
Um 7.300 € zu hoch angesetzt. Ihr Margenbericht und Ihre Einkaufsprognose verwenden jetzt den Preis des Schreibtischs.
Geprüftes EE-Modell: Budget für 100 Lampen
1.200 €
Das Angebot für die Lampe bleibt bei 12 € mit 3 Tagen Lieferzeit. Das Angebot für den Schreibtisch ist eine eigene Zeile.
Beispielhafte Berechnung auf Basis der Musterdaten; keine Datenbankaufrufe und keine gemessenen finanziellen Verluste.
Wird bei jedem Import eine neue Lieferanten-ID erzeugt, verteilen sich Einkäufe auf doppelte Profile. Ausgabensummen und Lieferantenvergleiche werden dadurch irreführend.
Entity Enricher
Deklarierte stabile Schlüssel lassen wiederkehrende Entitäten zusammenlaufen. Optionale semantische IDs helfen bei abweichenden Bezeichnungen, wobei die Treffer weiterhin geprüft werden müssen.
Ein Verbindungsschlüssel, der mit product_sku beginnt, ersetzt keinen Index, der mit supplier_id beginnt. Rückwärtssuchen können teuer werden, wenn Ihr Katalog wächst.
Entity Enricher
EE erzeugt strukturelle Indizes für seine Beziehungen, einschließlich umgekehrter Verbindungssuchen, und vermeidet redundante Indizes mit gleichem führenden Präfix. Passen Sie weitere Indizes an Ihre tatsächlichen Abfragen an.
Ihr JSON erhält ein neues Angebotsfeld, die Zieltabelle oder das Import-SQL jedoch nicht. Neue Daten lassen sich nicht laden oder erreichen nie die Berichte, die sie benötigen.
Entity Enricher
Das veröffentlichte Schema bestimmt sowohl die Tabellenstruktur als auch die Datenprojektion. Zeigen Sie unterstützte Migrationen vor der Veröffentlichung in der Vorschau an; nicht unterstützte Transformationen werden blockiert.
Nach einem Import bricht eine Verbindung ab. Ohne Replay-Regeln kann ein erneuter Versuch Duplikate erzeugen; eine ältere Aktualisierung kann ein neueres Angebot überschreiben.
Entity Enricher
EE liefert geordnete Zustellung, identitätsbasierte Upserts und Revisionsschutz. Der PostgreSQL-Client wendet einen Batch in einer Transaktion an und bestätigt nach dem Commit.
Das Modell liefert JSON, doch einem Angebot fehlt ein erforderlicher Schlüssel oder das Ziel verweigert den Schreibvorgang. Eine Erfolgsmeldung allein kann fehlende Produkte und Angebote verbergen.
Entity Enricher
Aufnahmerichtlinien können eine Entität ablehnen oder unvollständige Unterelemente auslassen. EE meldet Teilergebnisse und verfolgt die Replikat-Zustellung separat, sodass Sie erkennen, was korrigiert werden muss.
Das erneute Schreiben unveränderter Angebote verbraucht Datenbankressourcen, aktualisiert Indizes unnötig und erzeugt Rauschen in der nachgelagerten Änderungsverarbeitung.
Entity Enricher
EE erkennt unveränderte Entitätszustände und schützt Zeilenaktualisierungen vor unveränderten Werten. Konsumenten können dem Delta-Feed für Änderungen einschließlich Löschungen folgen.
Prüfen Sie vor der Veröffentlichung Identität, Zugehörigkeit und Bedeutung jedes Felds. EE macht diese Entscheidungen ausführbar, kann aber nicht belegen, dass Ihr Geschäftsmodell korrekt ist. Semantisches Matching kann Fehler machen, und die Abfrageleistung hängt weiterhin von Last und Datenbankgröße ab.
Die letzte Anreicherung ersetzt den aktuellen Stand: Fehlende Werte können frühere Werte löschen, und eine kürzere Liste zugehöriger Angebote entfernt ausgelassene Angebote. Führen Sie bei Bedarf eine separate Historie. Unvollständige oder abgelehnte Daten müssen korrigiert und erneut übermittelt werden; ein Zustellstatus bedeutet keine automatische Korrektur.
Supabase MCP ist nützlich, wenn ein Agent eine Datenbank inspizieren und eigenes SQL schreiben soll. EE ist nützlich, wenn derselbe Datenvertrag dauerhaft konsistente relationale Aktualisierungen erzeugen muss. Sie können Supabase PostgreSQL als Ziel für den Sync-Client von EE verwenden, sofern Verbindungs- und Datenbankberechtigungen dies zulassen. Die Zugriffsrichtlinien Ihrer Anwendung konfigurieren weiterhin Sie selbst.
Geprüft am 10. September 2026. Supabase bietet Migrationen und Advisors, die fehlende Indizes melden; das Besondere an EE ist, dass Regeln aus dem geprüften Anreicherungsschema generiert und angewendet werden.