Användardefinierade scheman för dedikerade SQL-pooler i Azure Synapse Analytics

Den här artikeln fokuserar på att ge flera tips för hur du använder T-SQL-användardefinierade scheman för att utveckla lösningar i en dedikerad SQL-pool.

Scheman för programgränser

Traditionella informationslager använder ofta separata databaser för att skapa programgränser baserat på antingen arbetsbelastning, domän eller säkerhet.

Ett traditionellt SQL Server informationslager kan till exempel innehålla en mellanlagringsdatabas, en informationslagerdatabas och vissa data mart-databaser. I den här topologin fungerar varje databas som en arbetsbelastning och säkerhetsgräns i arkitekturen.

En dedikerad SQL-pool kör däremot hela arbetsbelastningen för informationslagret i en databas. Korsdatabaskopplingar tillåts inte. En dedikerad SQL-pool förväntar sig att alla tabeller som används av informationslagret lagras i samma databas.

Anteckning

SQL-poolen stöder inte frågor mellan databaser av något slag. Därför måste implementeringar av informationslager som utnyttjar det här mönstret revideras.

Rekommendationer

Följande är 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 i en dedikerad SQL-pool för att köra hela arbetsbelastningen för informationslagret.
• Konsolidera din befintliga informationslagermiljö för att använda en dedikerad SQL-pooldatabas.
• 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 den dedikerade SQL-pooldatabasen.

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

• Ta bort de äldre schemanamnen och börja om från början.
• 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 för att återskapa den gamla schemastrukturen.

Anteckning

Vid första inspektion alternativ 3 kan verka som det mest tilltalande alternativet. Djävulen är dock i detalj. Vyer är skrivskyddade i en dedikerad SQL-pool. 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 data warehouse
GO
CREATE TABLE [stg].[customer] -- create staging tables in the stg schema
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[customer] -- create data warehouse tables in the edw schema
(       CustKey BIGINT NOT NULL
,       ...
);

Behåll äldre schemanamn genom att vänta i förväg till tabellnamnet. Använd scheman för arbetsbelastningsgränsen:

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- edw defines the data warehouse 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 data warehouse boundary
(       CustKey BIGINT NOT NULL
,       ...
);

Behåll äldre schemanamn med hjälp av vyer:

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- stg defines the data warehouse 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 data warehouse tables in the data warehouse 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 behöver granskas av databasens säkerhetsmodell. 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.

Nästa steg

Fler utvecklingstips finns i utvecklingsöversikt.