Schemi definiti dall'utente all'interno di Synapse SQL

  • Articolo

Nelle sezioni seguenti sono disponibili vari suggerimenti per l'uso di schemi definiti dall'utente T-SQL per sviluppare soluzioni all'interno di Synapse SQL.

Schemi per i limiti dell'applicazione

L'architettura di analisi tradizionale usa spesso database separati per creare limiti dell'applicazione in base al carico di lavoro, al dominio o alla sicurezza. Ad esempio, un'infrastruttura di analisi SQL Server tradizionale può includere un database di gestione temporanea, un database di analisi e database data mart. In questa topologia ogni database opera come carico di lavoro e limite di sicurezza nell'architettura.

Synapse SQL esegue invece l'intero carico di lavoro di analisi all'interno di un database. I join tra database non sono consentiti. Synapse SQL prevede che tutte le tabelle usate dal warehouse vengano archiviate all'interno di un 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.

Suggerimenti sullo schema definiti dall'utente

Sono inclusi i consigli per consolidare carichi di lavoro, sicurezza, dominio e limiti funzionali usando schemi definiti dall'utente:

  • Usare un database per eseguire l'intero carico di lavoro di analisi.
  • Consolidare l'ambiente di analisi esistente per usare un 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 dispone di uno slate pulito. Usare il nome del database precedente come base per gli schemi definiti dall'utente nel database SQL di Synapse.

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

  • Rimuovere i nomi degli schemi legacy e ricominciare dall'inizio.
  • Mantenere i nomi dello schema legacy in attesa del nome dello schema legacy al nome della tabella
  • Conservare i nomi dello schema legacy implementando le viste sulla tabella in uno schema aggiuntivo, che crea nuovamente la struttura dello schema precedente.

Nota

Nella prima ispezione, l'opzione 3 potrebbe sembrare la scelta più interessante. Le visualizzazioni vengono lette solo 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. Se si usano già visualizzazioni nell'architettura, è consigliabile dare questo pensiero aggiuntivo.

Esempio

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 dello schema legacy in sospeso con il 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
,       ...
);

Conservare i nomi dello schema legacy usando le visualizzazioni.

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 dello schema richiede una revisione del modello di sicurezza per il database. In molti casi, è possibile semplificare il modello di sicurezza assegnando 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 i ruoli del database e gli utenti .

Passaggi successivi

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