Schemi definiti dall'utente in Synapse SQL

  • Articolo

Nelle sezioni seguenti vengono forniti diversi suggerimenti relativi all'uso di schemi definiti dall'utente T-SQL per sviluppare soluzioni all'interno di Synapse SQL.

Schemi per i limiti dell'applicazione

Nell'architettura di analisi tradizionale si usano spesso database separati per creare i limiti dell'applicazione in base a carico di lavoro, dominio o sicurezza. Ad esempio, un'infrastruttura di analisi di SQL Server tradizionale può includere un database dell'area di gestione temporanea, un database di analisi e database del data mart. In questa topologia ogni database funge da limite di sicurezza e carico di lavoro nell'architettura.

Synapse SQL esegue invece l'intero carico di lavoro di analisi all'interno di un unico database. I join tra database non sono consentiti. Synapse SQL prevede che tutte le tabelle usate dal data warehouse siano archiviate all'interno di un unico database.

Nota

I pool SQL dedicati non supportano query tra database di qualsiasi tipo. Di conseguenza, le implementazioni di analisi che sfruttano questo modello dovranno essere modificate. Il pool SQL serverless supporta query tra database.

Raccomandazioni sugli schemi definiti dall'utente

Di seguito sono incluse le raccomandazioni per consolidare i limiti funzionali e relativi a carichi di lavoro, sicurezza, dominio usando schemi definiti dall'utente:

  • Usare un unico database per eseguire l'intero carico di lavoro di analisi.
  • Consolidare l'ambiente di analisi esistente in modo che usi un unico database.
  • Sfruttare gli schemi definiti dall'utente per fornire il limite implementato in precedenza tramite database.

Se gli schemi definiti dall'utente non sono stati usati in precedenza, si ha a disposizione una tabula rasa. Usare il nome del database precedente come base per gli schemi definiti dall'utente nel database di Synapse SQL.

Se gli schemi sono già stati usati, sono disponibili alcune opzioni:

  • Rimuovere i nomi degli schemi legacy e ricominciare dall'inizio.
  • Mantenere i nomi degli schemi legacy anteponendo il nome dello schema legacy al nome della tabella
  • Mantenere i nomi degli schemi legacy implementando viste sulla tabella in uno schema aggiuntivo, che ricrea la struttura dello schema precedente.

Nota

A prima vista, l'opzione 3 può sembrare quella più interessante. Le viste sono di sola lettura in Synapse SQL. Qualsiasi modifica di dati o tabelle dovrà essere eseguita sulla tabella di base. L'opzione 3 introduce anche un livello di viste nel sistema. È consigliabile valutare attentamente questo aspetto se si usano già viste nell'architettura.

Esempi

Implementare schemi definiti dall'utente in base ai nomi di database.

CREATE SCHEMA [stg]; -- stg previously database name for staging database
GO
CREATE SCHEMA [edw]; -- edw previously database name for the analytics
GO
CREATE TABLE [stg].[customer] -- create staging tables in the stg schema
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[customer] -- create analytics tables in the edw schema
(       CustKey BIGINT NOT NULL
,       ...
);

Mantenere i nomi di schemi legacy anteponendoli al nome della tabella. Usare schemi per il limite del carico di lavoro.

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- edw defines the analytics boundary
GO
CREATE TABLE [stg].[dim_customer] --pre-pend the old schema name to the table and create in the staging boundary
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[dim_customer] --pre-pend the old schema name to the table and create in the analytics boundary
(       CustKey BIGINT NOT NULL
,       ...
);

Mantenere i nomi di schemi legacy usando viste.

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- stg defines the analytics boundary
GO
CREATE SCHEMA [dim]; -- edw defines the legacy schema name boundary
GO
CREATE TABLE [stg].[customer] -- create the base staging tables in the staging boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE TABLE [edw].[customer] -- create the base analytics tables in the analytics boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE VIEW [dim].[customer] -- create a view in the legacy schema name boundary for presentation consistency purposes only
AS
SELECT  CustKey
,       ...
FROM    [edw].customer
;

Nota

Qualsiasi modifica nella strategia relativa agli schemi richiede una revisione del modello di sicurezza per il database. In molti casi è possibile semplificare il modello di sicurezza assegnando le autorizzazioni a livello di schema.

Se sono necessarie autorizzazioni più granulari, è possibile usare i ruoli del database. Per altre informazioni sui ruoli del database, vedere l'articolo Gestire ruoli e utenti del database.

Passaggi successivi

Per altri suggerimenti sullo sviluppo, vedere Synapse SQL pool development overview (Panoramica sullo sviluppo per il pool Synapse SQL).