# Binding di database specifiche dell'installazione

Il Metadata Catalog separa il Workspace Database logico dalla Database Binding che lo rende
raggiungibile in una specifica installazione. Esiste un solo Workspace Database per `workspace_id`
e una sola binding attiva nel catalogo di ciascuna installazione; per esempio PSD usa REST in locale
e PostgreSQL diretto sul server senza diventare due database distinti.

Nel modello finale il catalogo è autorevole per engine, nome fisico, schema, capability e binding,
mentre `thoth-workspaces.yaml` conserva l'identità del workspace. Gli attuali campi DWH dei
descriptor sono una sorgente di bootstrap da importare e confrontare durante un cutover esplicito,
non una seconda fonte di verità permanente.

## Considered Options

- Conservare un record database per ogni trasporto avrebbe duplicato identità, struttura e
  metadati dello stesso DWH fra locale e server.
- Conservare permanentemente i dati DWH sia nello YAML sia nel catalogo avrebbe introdotto
  conflitti non risolvibili deterministicamente.
- Rendere globali le binding avrebbe mescolato endpoint e credenziali che appartengono a
  installazioni con topologie e confini di sicurezza differenti.

## Consequences

La lista amministrativa unisce workspace YAML, database configurati e record orphaned. Il cutover
deve importare e confrontare la configurazione esistente prima di rimuoverla dai descriptor; il
runtime non deve osservare simultaneamente due autorità discordanti.