Collega un database a uno schema ed Entity Enricher mantiene le tue entità arricchite come tabelle relazionali di tua proprietà: una vera tabella company con una colonna revenue — non un file di esportazione. Scarica una volta uno snapshot SQL pronto all'uso, quindi mantieni il tuo database convergente con un feed delta incrementale di upsert idempotenti.
Archivia una volta, proietta su richiesta. Gli arricchimenti scrivono lo stato corrente dell'entità nel livello delle entità; ogni database collegato è una proiezione di quello stato, fornita come snapshot una tantum più un feed di delta che l'utente conferma. La modifica di uno schema comporta una nuova proiezione, mai una migrazione dei dati.
database_sync: false); gli arricchimenti degli altri utenti continuano a essere instradati normalmente..sql (tabelle + dati) e lo applichi al suo PostgreSQL. Il DDL include indici di join e chiavi esterne (le righe figlio e di collegamento vengono eliminate in cascata quando un'entità viene rimossa). L'intestazione del file indica da quale cursore delta riprendere.Ogni tipo di entità dispone di una Chiave del database: l’insieme di colonne che le sue tabelle utilizzano come indice univoco e come target dei conflitti in fase di upsert. Quando collega un database, una fase di classificazione basata su AI propone l’intero modello del database (chiavi, tipi di colonna, indici, proprietà) da sottoporre alla sua revisione, con un semplice criterio di ripiego: l’ID semantico dell’oggetto, se presente; altrimenti un campo di tipo Id (id, product_id, …); altrimenti le chiavi naturali dell’oggetto. Nelle sue tabelle un ID semantico viene creato come colonna semantic_id: il nome id resta libero per un suo utilizzo. Può modificarle in qualsiasi momento nella scheda “Model” del database: una volta pubblicata, è una modifica equivalente a una migrazione, quindi scarichi nuovamente lo snapshot al termine. Nulla viene scritto nel suo database finché lo schema non viene pubblicato da quella scheda (il solo collegamento non crea alcuna tabella né alcuna riga).
Una chiave di database non è mai nullable. Un valore null non corrisponde ad alcuna riga, quindi invece di aggiornare l'entità inserirebbe un nuovo duplicato a ogni arricchimento — ecco perché un arricchimento la cui chiave risulta vuota viene rifiutato anziché salvato. L'editor tiene separati i due flag e uno schema che li imposta entrambi viene rifiutato quando lo salva o collega un database, indicando i due modi per correggerlo: rendere la proprietà sempre presente oppure basare la chiave del tipo su un'altra proprietà.
Quando una database key è un campo di testo arricchito anziché un semantic ID, il valore memorizzato sarà la risposta del modello — non il testo inviato. Indicare un'azienda come Embraer nella richiesta non vincola quel campo: l'arricchimento può rispondere Embraer S.A. — un'ortografia corretta, un suffisso legale esteso, un disambiguatore rimosso — ed è questo il valore che identifica la riga. Di conseguenza, cercare la riga con il valore inviato può non dare risultati (utilizzi le entity_keys restituite con ogni arricchimento salvato) e un'esecuzione successiva formulata in modo diverso produce una chiave diversa: inserisce una seconda riga invece di aggiornare la sua. È il comportamento previsto per qualsiasi chiave composta da testo arricchito. La soluzione è un semantic ID su quel tipo: le varianti di uno stesso nome si risolvono in un'unica identità stabile, così la riga sopravvive a qualunque grafia usata dal modello. Lo attivi al momento della generazione dello schema — aggiungerlo in seguito comporta la modifica di ogni oggetto.
Gli oggetti annidati all’interno di array diventano tabelle a sé stanti, con righe di giunzione che ne preservano l’ordine; gli oggetti valore privi di identità restano appiattiti nelle colonne del genitore. I nomi delle proprietà vengono usati alla lettera (tra virgolette) — i nomi delle colonne sono i nomi delle proprietà dello schema, abbreviati solo quando un percorso annidato supererebbe la lunghezza consentita da PostgreSQL per un nome.
La proiezione è deterministica — lo stesso schema viene sempre mappato sulle stesse tabelle e colonne. I nomi delle proprietà diventano nomi di colonna verbatim (tra virgolette); i nomi dei tipi vengono convertiti in snake_case per i nomi delle tabelle (VideoGame → video_game). L'unica eccezione è la lunghezza: PostgreSQL non può contenere un identificatore oltre i 63 byte, quindi un percorso profondamente annidato accorcia i suoi oggetti superiori per adattarsi (morphological_description_ → morpdesc_) — lo stesso prefisso per ogni colonna di quell'oggetto, mostrato e modificabile nella scheda Modello prima del collegamento. Una proprietà può anche eliminare del tutto il proprio prefisso per corrispondere a una colonna già presente nel proprio database (product_identifiers.stock_keeping_unit → sku) — l'interruttore di collegamento accanto al nome nella scheda Modello. Ogni tabella contiene una colonna _sync_revision usata per mantenere convergenti i replay.
| Nel vostro schema | Nel vostro database |
|---|---|
| Oggetto con identità (ID semantico o chiavi) | La propria tabella; le chiavi del database diventano l'indice univoco e la destinazione dell'upsert |
| Campo scalare (string, number, boolean) | Una colonna tipizzata (TEXT, BIGINT, NUMERIC, BOOLEAN) |
| Insieme chiuso (un campo limitato a un elenco di valori) | Una semplice colonna TEXT — nessun CHECK, nessun tipo enum del database. L'elenco viene applicato quando l'AI risponde, quindi aggiungere in seguito un valore non comporta mai una migrazione del database. Aggiunga un proprio vincolo, se lo desidera — la sincronizzazione non lo modifica mai |
| Campo nullable o non nullable | Per impostazione predefinita un campo non annullabile diventa una colonna NOT NULL, in abbinamento al filtro di qualità qui sotto: con il filtro più severo anche i riferimenti obbligatori ricevono chiavi esterne NOT NULL; disattivi l'applicazione del vincolo — al momento della registrazione oppure in seguito: una modifica successiva alla prima sincronizzazione viene distribuita come migrazione protetta nel feed — per mantenere annullabili tutte le colonne e lasciare che sia il solo filtro a garantire la completezza |
| Campo multilingue | Un'unica colonna JSONB che contiene ogni lingua |
| Oggetto valore incorporato (senza identità) | Appiattito in colonne con prefisso (dimensions_width) |
| Array di oggetti valore | Una tabella figlia con chiave sul genitore, ordinata, con eliminazione a cascata |
Array di entità / relazione $ref | Una tabella di giunzione che collega le righe di origine e di destinazione, con l'ordine preservato |
Campo chiave (identifying) | Un indice secondario per ricerche rapide |
| Indice modellato sulla query (elenco ordinato di campi) | Un indice multi-colonna per ogni forma dichiarata, ordinato come la query della schermata a elenco che serve — prima le sfaccettature e gli insiemi chiusi, per ultima la colonna di ordinamento o di intervallo, campi multilingue inclusi (una forma di questo tipo viene creata una volta per ogni lingua ricevuta dal database); proposto dal passaggio di classificazione con una motivazione, curato nella scheda Modello, più indici per entità |
| Campo di ricerca (intento di indicizzazione) | Un indice a trigrammi (pg_trgm) sul testo che i campi di ricerca confrontano per frammenti — per lingua e senza limiti sulle colonne multilingue; mai su un valore a tendina, che va invece in un indice modellato sulla query (compresi quelli multilingue — un indice di questo tipo viene creato una volta per ogni lingua ricevuta dal database); ignorato (nessuna operazione) sulle repliche prive dell'estensione finché un proprietario del database non la installa |
| Coppia di coordinate (latitudine + longitudine) | Un unico indice spaziale sulla coppia (GiST nativo di PostgreSQL, senza estensioni) — query per raggio, nearest-neighbor e viewport della mappa |
| Coppia di intervallo (estremi iniziale + finale) | Un unico indice di intervallo sulla coppia — query di sovrapposizione e del tipo "quale valore era in vigore in questa data" |
Un database può sincronizzare più di uno schema. I tipi di entità con lo stesso nome tra gli schemi collegati confluiscono nella stessa tabella, uniti dalla loro chiave di database — gli arricchimenti di ciascuno schema aggiornano soltanto le proprie colonne, così un'azienda arricchita da due schemi diventa un'unica riga che contiene entrambi i set di colonne. I tipi esclusivi di uno schema aggiungono semplicemente le proprie tabelle, distribuite tramite un delta di migrazione automatico nel feed — senza bisogno di riscaricare nulla.
Quando colleghi uno schema, un passaggio di confronto mostra esattamente quali tabelle verranno unite (con le loro chiavi e le colonne aggiunte) e quali sono nuove; uno schema che condivide una tabella adotta le chiavi di database esistenti di quella tabella, mostrate per la tua revisione. Se gli schemi non condividono nulla, il flusso suggerisce invece un database dedicato. Lo scollegamento di uno schema non tocca mai il tuo database — le tabelle sincronizzate rimangono.
Lo scollegamento di uno schema, o l'eliminazione di una sincronizzazione, lascia due elementi dalla nostra parte: lo stato dell'entità memorizzato che nessuno scrive più e le proprietà del database associate allo schema (chiavi del database, tipi di colonna, indici, titolarità). Entrambe le conferme propongono di rimuoverli, e solo per gli schemi rimasti senza alcun database — uno ancora sincronizzato altrove conserva tutto. Lo schema stesso, i suoi record di arricchimento e i suoi costi non vengono mai interessati.
Uno schema collegato ha un contratto pubblicato: la versione che i vostri arricchimenti e il vostro database utilizzano effettivamente. La modifica dello schema interviene solo su una copia di lavoro — le modifiche testuali vengono applicate automaticamente, mentre le modifiche strutturali (nuovi campi, cambiamenti di tipo o di chiave) restano in attesa finché non premete Pubblica. La pubblicazione mostra un'anteprima dell'impatto esatto e invia la migrazione corretta nel feed delta: le nuove colonne arrivano come delta ALTER TABLE, mentre le modifiche più consistenti (una nuova chiave del database, un cambiamento di tipo) vengono eseguite come migrazioni protette sul vostro database — se i dati le bloccano (un valore di chiave mancante o duplicato), il feed si mette in pausa segnalando il problema esatto e riprova automaticamente una volta risolto.
La pubblicazione si trova nella scheda Model del database (il Workflow Editor mostra un banner che rimanda lì mentre lo schema è collegato). Prima di pubblicare, mostra entrambi i lati: il contratto su cui si basa oggi il suo database e un diff di tutto ciò che la sua copia di lavoro modificherebbe. Non è convinto di una modifica? Ripristina la versione pubblicata riporta indietro il contratto — operazione annullabile, e la bozza che ha messo da parte resta ripristinabile per 24 ore.
Ricollegare uno schema modificato mentre era scollegato funziona allo stesso modo: la sincronizzazione ricorda ciò che il vostro database possiede già e invia solo la differenza, più un aggiornamento dello snapshot per le righe scritte nel frattempo. Nessun DROP manuale, mai.
Lo stesso impegno vale per i nostri aggiornamenti. Quando una nuova versione migliora il modo in cui gli schema vengono mappati sulle tabelle, la Sua sincronizzazione viene migrata automaticamente: le modifiche additive arrivano nel feed da sole. Se un aggiornamento dovesse ridefinire la struttura di tabelle già presenti, non tocchiamo mai i Suoi dati senza preavviso: la consegna si mette in pausa e la pagina Database Sync Le chiede di applicarlo, mostrando prima esattamente quali sono le modifiche.
Anche l'arricchimento multilingue è di prima classe qui: i valori localizzati arrivano come colonne JSONB che contengono ogni lingua dell'arricchimento — {"en": "Headache", "fr": "Céphalée"} — così un unico database serve tutte le sue localizzazioni contemporaneamente. Scelga una lingua direttamente nelle sue query (name->>'fr') e i payload JSON dei delta contengono gli stessi oggetti con chiavi per lingua.
Ogni database risponde a una domanda al momento della registrazione: quando un arricchimento presenta dei vuoti — campi non annullabili non compilati — cosa viene scritto? Le tre risposte formano una scala. Niente: basta un vuoto in qualunque punto, anche all'interno di un oggetto annidato, e l'entità viene rifiutata. L'entità, senza i figli incompleti (impostazione predefinita): la riga dell'entità stessa deve essere completa, ma un figlio difettoso viene saltato e segnalato invece di compromettere l'intero arricchimento. Tutto: i vuoti diventano NULL e nulla viene rifiutato — ma lo stato dell'entità segue la regola dell'ultima scrittura, l'arricchimento più recente è la riga, quindi un'esecuzione parziale successiva cancella ciò che una precedente aveva compilato. È proprio questa cancellazione che i due gradini severi servono a impedire.
Gli arricchimenti che non superano il controllo vengono comunque salvati come record e attivano comunque il webhook record.created — con database.saved impostato su false — indicando esattamente quali campi obbligatori mancavano, così i dati incompleti non spariscono mai silenziosamente. Per ogni campo mancante viene inoltre indicato se un modello lo ha dichiarato sconosciuto oppure lo ha semplicemente omesso: nel primo caso serve un modello più potente, una ricerca web o un documento di origine, nel secondo una verifica dello schema o dell'input. Solo i campi della chiave del database sono sempre obbligatori: un arricchimento privo di un valore di chiave viene rifiutato a qualunque livello.
Sui gradini severi, una casella di controllo replica lo stesso contratto nel suo database sotto forma di colonne NOT NULL su ogni campo sempre presente. Con il gradino più severo il vincolo si estende anche alle chiavi esterne dei riferimenti obbligatori: nessuna riga ammessa può esserne priva. Con salta i figli incompleti restano annullabili, e in modo deliberato: un elemento di elenco privo di un proprio valore viene scartato, mentre un riferimento uno-a-uno condiviso la cui destinazione è incompleta (lo stadio di cui nessuno conosce l'anno di apertura) viene scollegato — quella destinazione non viene né scritta né aggiornata e la riga salvata non punta a nulla, il che scrive NULL esattamente in quelle colonne di chiave esterna. Entrambi i casi sono segnalati nella risposta dell'arricchimento, e i vuoti nei campi di primo livello comportano sempre il rifiuto. Cambiare la policy dopo la prima sincronizzazione non è mai lavoro perso: viene distribuita come migrazione protetta nel feed, convalidata sulle righe già presenti nel suo database.
Un secondo controllo intercetta le identità duplicate: quando due elementi della stessa lista si risolvono nella stessa chiave di database — un modello che inventa un unico id per due aziende diverse, oppure una chiave che non le distingue — può esistere una sola riga, quindi viene scritta l'ultima e le precedenti vengono scartate, secondo la stessa regola last-write-wins applicata ovunque. Ogni collisione viene segnalata con i valori identificativi di entrambi gli elementi e un verdetto: un duplicato ripeteva gli stessi valori e non ha perso nulla, uno scarto in conflitto ha perso i valori che indica — o il modello ha ripetuto la stessa cosa con valori rumorosi, oppure si tratta di cose diverse e la chiave richiede una proprietà discriminante (una regione, un anno, una versione). La lista viene conservata sul record, così una scrittura parziale indica ciò che ha perso anche molto tempo dopo che la risposta non è più disponibile.
Un aspetto da tenere presente prima di rieseguire l'enrichment: per un elenco che appartiene al proprio elemento padre, l'elenco dell'enrichment più recente è l'elenco valido. Una riga figlia che l'ultima risposta non ripete viene eliminata dal database — è così che una rimozione autentica arriva fino a lei, e la risposta non la segnala. Ciò è rilevante quando l'elenco è di quelli che il model richiama dalla memoria anziché enumerare: chieda due volte gli isotopi di un elemento o i premi di una persona e la seconda risposta potrebbe essere più breve, rimuovendo righe che erano corrette. Conservi la sua cronologia se le serve l'unione di tutte le esecuzioni.
Gli arricchimenti raggiungono da soli un database collegato. Tutto il resto — un risultato rifiutato dal gate prima della correzione dello schema, un'esecuzione esclusa deliberatamente oppure un output da rivedere o correggere prima — passa dall'invio dei record al database: selezionarli nella pagina Cronologia oppure chiamare l'API da un workflow.
Il ciclo completo. Eseguire l’arricchimento con database sync disattivato, rimodellare o approvare il risultato nel proprio workflow, quindi inviarlo. Ciò che viene inviato è nuovamente convalidato rispetto al contratto pubblicato dello schema e attraversa lo stesso gate di ammissione di un arricchimento: un’iniezione non potrà mai scrivere ciò che un arricchimento non avrebbe potuto scrivere.
Due dettagli da conoscere. L'invio di un record invariato lo memorizza sotto quel record. L'invio di un output modificato crea un nuovo record che rimanda all'originale, poiché i record costituiscono una traccia di audit: non cambiano mai sotto i dati che li citano, quindi ciò che il vostro database contiene è sempre riconducibile a un record che riporta esattamente quei valori. Inoltre, la convalida utilizza il contratto così com'è oggi — se lo schema è cambiato dopo la produzione del record, la pagina Cronologia lo segnala prima dell'invio.
La pagina Cronologia mostra inoltre, per ogni record, se è arrivato al database: inviato, inviato parzialmente o rifiutato con la relativa motivazione. Disponibile dalla web app, dall'API, da MCP, n8n e Make.
Il feed è una coda FIFO rigorosa per ciascun database: si recupera una finestra (facoltativamente in lease, così che il batch di un worker interrotto venga riconsegnato prima di qualsiasi dato più recente), si applica e si conferma. Le notifiche webhook sono soggette a debounce — ogni nuovo delta azzera il timer del periodo di quiete, così che una raffica di arricchimenti venga annunciata una sola volta; un ritardo massimo configurabile limita l'attesa e una pagina di recupero piena viene notificata immediatamente. Due opzioni di eliminazione controllano ciò che Entity Enricher conserva: eliminare le copie dei delta consegnati al momento della conferma e — per la minimizzazione dei dati — eliminare lo stato stesso dell'entità una volta che tutti i database collegati allo schema lo hanno ricevuto. Ciascuna opzione accetta un ritardo facoltativo in giorni: le copie consegnate permangono per quel periodo dopo la conferma (una finestra di replay) e un'entità consegnata viene conservata finché non trascorre quel periodo senza aggiornamenti, con un'eliminazione oraria che rimuove ciò che è scaduto. Si noti che l'eliminazione dello stato è una minimizzazione, non una cancellazione: i record di arricchimento restano finché non vengono eliminati e l'opzione disattiva l'unione tra arricchimenti per le entità eliminate.
Un endpoint di checksum per tabella vi consente di verificare in qualsiasi momento che la vostra replica sia convergente, senza scaricare nuovamente nulla.
Tutto si trova in un unico punto dell'applicazione — Database Sync, subito sotto Cronologia nella barra laterale: registrare un database su qualsiasi schema (con la revisione della chiave database), collegare o scollegare schemi, mettere in pausa il flusso di arricchimento di uno schema collegato tramite il relativo interruttore (nessun nuovo dato né notifica fino alla riattivazione — le pubblicazioni di schema continuano comunque a inviare il proprio DDL, e gli arricchimenti eseguiti durante la pausa raggiungono la replica solo tramite un nuovo pull dello snapshot), modificarne le opzioni, visualizzare l'endpoint webhook e rivelarne la chiave di firma, scaricare lo snapshot, esplorare lo stato attuale dell'entità, ispezionare la coda dei delta in attesa (in sola lettura — il cursore del suo flusso di lavoro non viene mai toccato) e visualizzare un diagramma entità-relazione delle tabelle generate con le relative chiavi e giunzioni. Su un database sync con più database il diagramma può concentrarsi su un solo schema: tabelle, colonne e collegamenti alimentati dagli altri schemi vengono attenuati in grigio — restando comunque visibili al loro posto — così da vedere esattamente che cosa apporta ciascuno schema alle tabelle condivise.
Quando più database finiscono sulla stessa macchina, il pulsante Sync hosts della barra degli strumenti elimina la procedura di associazione per singolo database: associ la macchina una volta sola, poi le assegni le registrazioni. L'host rivendica ciascuna registrazione, crea il database fisico se non esiste e avvia la sincronizzazione — così registrare un database diventa una decisione che si prende qui, non una sessione di terminale sul server. L'associazione avviene per singolo server Entity Enricher, quindi una stessa macchina può servire più istanze affiancate.
Un'istruzione che il suo database rifiuta — di solito per duplicati preesistenti sotto un nuovo indice univoco — non blocca la coda che la segue. Il batch di quell'arricchimento viene messo in quarantena, il flusso prosegue e il batch compare nella scheda Quarantena con l'istruzione rifiutata dal suo database. Corregga la causa e reinietti — operazione che riproietta l'entità dal suo stato attuale invece di rieseguire un'istruzione ormai obsoleta — oppure lo elimini.
GET /api/databases//changes?since=…&format=sql quindi POST /api/databases//ack.Utilizzate Supabase? Il nostro confronto con Supabase MCP mostra come le regole di relazione e di sincronizzazione di EE proteggono un catalogo prodotti, con JSON e piccoli diagrammi di tabelle.
Nulla nella sincronizzazione viene mai eseguito sul server del database — ogni percorso sopra è un consumer in uscita che si connette a qualsiasi DSN gli venga fornito. Azure Database for PostgreSQL, OVHcloud, AWS RDS, Supabase o qualsiasi altra istanza gestita funziona esattamente come una self-hosted: puntare il consumer al DSN cloud (i provider gestiti di solito impongono il TLS, quindi aggiungere sslmode=require) e applicare.
--dsn all'istanza gestita.delta_available risveglia una Azure Function / AWS Lambda / funzione OVHcloud che preleva il feed REST, esegue l'SQL e conferma.Due regole mantengono sicuro qualsiasi consumer realizzato manualmente: eseguire le istruzioni di ogni batch in ordine, all'interno di un'unica transazione, e confermare solo dopo il commit. I delta sono idempotenti e protetti da revisione, quindi un crash prima della conferma significa semplicemente che il batch viene riconsegnato e la riapplicazione converge.
I database sono disponibili nei piani a pagamento (il piano stabilisce quanti se ne possono registrare). PostgreSQL è il dialetto di lancio; ogni database dichiara il proprio dialetto, mentre MySQL / MariaDB, SQL Server e Oracle sono in programma.