Dela via


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 data mart-databaser. 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 är inte tillåtna. Synapse SQL förväntar sig att alla tabeller som används av lagret lagras i en databas.

Anmärkning

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 ses över. 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 ange den gräns som tidigare implementerats med hjälp av databaser.

Om användardefinierade scheman inte har använts tidigare har du ett oskrivet blad. 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 på nytt
  • Behåll de gamla schemanamnen genom att lägga till det gamla schemanamnet till tabellnamnet.
  • Behåll de äldre schemanamnen genom att implementera vyer över tabellen i ett extra schema, vilket återskapar den gamla schemastrukturen.

Anmärkning

Vid första inspektionen kan alternativ 3 verka som det mest tilltalande valet. Vyer är endast läsbar 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 lägga till dem i 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
;

Anmärkning

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.