De JSON a una base de datos relacional
Una base de datos puede aceptar todas las inserciones y aun así darle un presupuesto de compra incorrecto. Vea cómo un precio mal ubicado corrompe un catálogo de productos y cómo Entity Enricher convierte las decisiones revisadas de identidad y relaciones en tablas y actualizaciones repetibles.
El agente interpreta su JSON y escribe SQL. Supabase MCP ejecuta ese SQL mediante apply_migration y execute_sql. Su agente o aplicación debe aportar las reglas de modelado, identidad e importaciones repetidas.
Usted revisa un esquema reutilizable, incluidas las claves y las relaciones compartidas o dependientes de un padre. El motor deriva tablas, restricciones e índices estructurales y, después, entrega los cambios de datos posteriores a través del mismo modelo. La IA ayuda a proponer el modelo; el código aplica sus reglas.
Esta comparación se refiere a un agente que construye a partir de JSON mediante Supabase MCP. Una aplicación Supabase bien diseñada también puede implementar estas salvaguardas. El modelo defectuoso que se muestra a continuación ilustra un riesgo de modelado, no un comportamiento predeterminado de Supabase ni una tasa de fallo medida.
Este catálogo ficticio contiene dos muestras de productos. El proveedor SUP-7 vende una lámpara por 12 € y un escritorio por 85 €. El proveedor es compartido; el precio y el plazo de entrega pertenecen a cada oferta.
[
{
"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
}
]
}
]En Entity Enricher, estos son ejemplos de esquema, no una importación automática de datos. Revise el esquema generado, marque el proveedor como compartido y las ofertas como propiedad del padre, y luego publique y enriquezca o inyecte los registros correspondientes. Los SKU y los ID de proveedor estables aportan la identidad en este ejemplo.
Mapeo defectuoso ilustrativo
| Columna y clave | Tipo SQL |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Columna y clave | Tipo SQL |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Actualizar SUP-7 con la oferta del escritorio sobrescribe el precio y el plazo de entrega de la lámpara. La clave foránea es válida. Los datos son erróneos. Este diseño también limita cada producto a un único proveedor.
Entity Enricher con el modelo revisado
| Columna y clave | Tipo SQL |
|---|---|
| skuPK | text |
| name | text |
| Columna y clave | Tipo SQL |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Columna y clave | Tipo SQL |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Se reutiliza una sola fila de proveedor. Cada par producto–proveedor tiene su propio precio y plazo de entrega. Añadir la oferta del escritorio deja intacta la oferta de la lámpara.
Nombres de tablas simplificados y claves naturales; se omiten los metadatos de sincronización. PK = clave primaria, FK = clave foránea. Las dos claves de oferta forman una única clave compuesta. Este ejemplo asume una sola oferta vigente por par; los historiales de precios, las divisas o los tramos de cantidad requieren modelado adicional.
Un comprador necesita 100 lámparas. Alterne entre la primera y la segunda importación para ver qué devuelve cada modelo.
Modelo defectuoso: presupuesto para 100 lámparas
8500 €
Sobrestimado en 7300 €. Su informe de márgenes y su previsión de compras utilizan ahora el precio del escritorio.
Modelo EE revisado: presupuesto para 100 lámparas
1200 €
La oferta de la lámpara sigue siendo de 12 € con un plazo de entrega de 3 días. La oferta del escritorio es una fila aparte.
Cálculos ilustrativos a partir de los datos de ejemplo; sin llamadas a la base de datos ni pérdidas financieras medidas.
Si se genera un nuevo ID de proveedor en cada importación, las compras se reparten entre perfiles duplicados. Los totales de gasto y las comparaciones entre proveedores resultan engañosos.
Entity Enricher
Las claves estables declaradas hacen converger las entidades repetidas. Los ID semánticos opcionales pueden ayudar cuando las etiquetas varían, con coincidencias que aún requieren revisión.
Una clave de unión que empieza por product_sku no reemplaza un índice que empieza por supplier_id. Las búsquedas inversas pueden volverse costosas a medida que crece su catálogo.
Entity Enricher
EE genera índices estructurales para sus relaciones, incluidas las búsquedas inversas en tablas de unión, y evita índices redundantes con el mismo prefijo inicial. Ajuste los demás índices a sus consultas reales.
Su JSON incorpora un campo de oferta, pero la tabla de destino o el SQL de importación no. Los nuevos datos no se cargan o nunca llegan a los informes que los necesitan.
Entity Enricher
El esquema publicado determina tanto la forma de las tablas como la proyección de los datos. Previsualice las migraciones compatibles antes de publicar; las transformaciones no admitidas se bloquean.
Una conexión se interrumpe después de una importación. Sin reglas de repetición, reintentar puede crear duplicados; una actualización antigua puede reemplazar una oferta más reciente.
Entity Enricher
EE proporciona entrega ordenada, upserts basados en la identidad y controles de revisión. El cliente de PostgreSQL aplica un lote en una transacción y confirma la recepción después del commit.
El modelo devuelve JSON, pero a una oferta le falta una clave obligatoria o el destino rechaza la escritura. Un simple mensaje de éxito puede ocultar productos y ofertas que faltan.
Entity Enricher
Las políticas de admisión pueden rechazar una entidad u omitir hijos incompletos. EE informa de los resultados parciales y hace un seguimiento independiente de la entrega de réplicas, de modo que pueda identificar qué necesita reparación.
Reescribir ofertas que no han cambiado consume trabajo de base de datos, mantiene índices innecesariamente y genera más ruido en el procesamiento posterior de los cambios.
Entity Enricher
EE detecta cuando el estado de una entidad no ha cambiado y evita actualizar filas con valores sin cambios. Los consumidores pueden seguir el feed de deltas para ver los cambios, incluidas las eliminaciones.
Revise la identidad, la propiedad y el significado de cada campo antes de publicar. EE hace que esas decisiones sean ejecutables; no puede demostrar que su modelo de negocio sea correcto. La correspondencia semántica puede cometer errores, y el rendimiento de las consultas sigue dependiendo de la carga de trabajo y del tamaño de la base de datos.
El último enriquecimiento sustituye el estado actual: los valores ausentes pueden borrar valores anteriores y una lista de ofertas propias más corta elimina las ofertas omitidas. Conserve un historial aparte cuando sea necesario. Los datos parciales o rechazados requieren corrección y reenvío; un estado de entrega no implica una reparación automática.
Supabase MCP resulta útil cuando quiere que un agente inspeccione una base de datos y escriba SQL personalizado. EE resulta útil cuando un mismo contrato de datos debe seguir produciendo actualizaciones relacionales coherentes. Puede usar Supabase PostgreSQL como destino del cliente de sincronización de EE, según los permisos de conexión y de base de datos. Las políticas de acceso de la aplicación siguen siendo responsabilidad suya.
Revisado el 10 de septiembre de 2026. Supabase ofrece migraciones y Advisors que señalan los índices faltantes; lo distintivo de EE es generar y aplicar reglas a partir del esquema de enriquecimiento revisado.