Användardefinierade scheman i Synapse SQL

I avsnitten nedan hittar du olika tips för hur du använder T-SQL-användardefinierade scheman för att utveckla lösningar i Synapse SQL.

Scheman för programgränser

Traditionell analysarkitektur använder ofta separata databaser för att skapa programgränser baserat på arbetsbelastning, domän eller säkerhet. En traditionell SQL Server analysinfrastruktur kan till exempel innehålla en mellanlagringsdatabas, en analysdatabas och databaser för data mart. I den här topologin fungerar varje databas som en arbetsbelastning och säkerhetsgräns i arkitekturen.

I stället kör Synapse SQL hela analysarbetsbelastningen i en databas. Korsdatabaskopplingar tillåts inte. Synapse SQL förväntar sig att alla tabeller som används av informationslagret lagras i samma databas.

Anteckning

Dedikerade SQL-pooler stöder inte frågor mellan databaser av något slag. Därför måste analysimplementeringar som utnyttjar det här mönstret revideras. Serverlös SQL-pool stöder frågor mellan databaser.

Användardefinierade schemarekommendationer

Här följer rekommendationer för att konsolidera arbetsbelastningar, säkerhet, domäner och funktionella gränser med hjälp av användardefinierade scheman:

  • Använd en databas för att köra hela analysarbetsbelastningen.
  • Konsolidera din befintliga analysmiljö för att använda en databas.
  • Använd användardefinierade scheman för att tillhandahålla den gräns som tidigare implementerats med hjälp av databaser.

Om användardefinierade scheman inte har använts tidigare har du en ren skiffer. Använd det gamla databasnamnet som grund för dina användardefinierade scheman i Synapse SQL-databasen.

Om scheman redan har använts har du några alternativ:

  • Ta bort de äldre schemanamnen och börja om
  • Behåll de äldre schemanamnen genom att vänta i förväg på det äldre schemanamnet till tabellnamnet
  • Behåll de äldre schemanamnen genom att implementera vyer över tabellen i ett extra schema, som återskapar den gamla schemastrukturen.

Anteckning

Vid första inspektionen kan alternativ 3 verka vara det mest tilltalande valet. Vyer är skrivskyddade i Synapse SQL. Alla data eller tabelländringar måste utföras mot bastabellen. Alternativ 3 introducerar också ett lager med vyer i systemet. Du kanske vill tänka på detta ytterligare om du redan använder vyer i din arkitektur.

Exempel

Implementera användardefinierade scheman baserat på databasnamn.

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
,       ...
);

Behåll de äldre schemanamnen genom att vänta i förväg på tabellnamnet. Använd scheman för arbetsbelastningsgränsen.

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
,       ...
);

Behåll de äldre schemanamnen med hjälp av vyer.

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
;

Anteckning

Alla ändringar i schemastrategin kräver en granskning av säkerhetsmodellen för databasen. I många fall kanske du kan förenkla säkerhetsmodellen genom att tilldela behörigheter på schemanivå.

Om mer detaljerade behörigheter krävs kan du använda databasroller. Mer information om databasroller finns i artikeln Hantera databasroller och användare .

Nästa steg

Fler utvecklingstips finns i Översikt över Synapse SQL-utveckling.