Door de gebruiker gedefinieerde schema's voor toegewezen SQL-pools in Azure Synapse Analytics

  • Artikel

Dit artikel bevat verschillende tips voor het gebruik van door de gebruiker gedefinieerde T-SQL-schema's voor het ontwikkelen van oplossingen in een toegewezen SQL-pool.

Schema's voor toepassingsgrenzen

Traditionele datawarehouses gebruiken vaak afzonderlijke databases om toepassingsgrenzen te maken op basis van workload, domein of beveiliging.

Een traditioneel SQL Server datawarehouse kan bijvoorbeeld een faseringsdatabase, een datawarehouse-database en een aantal datamart-databases bevatten. In deze topologie werkt elke database als een workload- en beveiligingsgrens in de architectuur.

Een toegewezen SQL-pool voert daarentegen de volledige datawarehouse-workload uit binnen één database. Databaseoverschrijdende joins zijn niet toegestaan. Toegewezen SQL-pool verwacht dat alle tabellen die door het magazijn worden gebruikt, worden opgeslagen in één database.

Notitie

SQL-pool biedt geen ondersteuning voor query's tussen databases. Daarom moeten datawarehouse-implementaties die gebruikmaken van dit patroon worden herzien.

Aanbevelingen

Hieronder volgen aanbevelingen voor het consolideren van workloads, beveiliging, domein en functionele grenzen met behulp van door de gebruiker gedefinieerde schema's:

  • Gebruik één database in een toegewezen SQL-pool om uw volledige datawarehouse-workload uit te voeren.
  • Consolideer uw bestaande datawarehouse-omgeving om één toegewezen SQL-pooldatabase te gebruiken.
  • Gebruik door de gebruiker gedefinieerde schema's om de grens te bieden die eerder is geïmplementeerd met behulp van databases.

Als er nog geen door de gebruiker gedefinieerde schema's zijn gebruikt, hebt u een schone lei. Gebruik de oude databasenaam als basis voor uw door de gebruiker gedefinieerde schema's in de toegewezen SQL-pooldatabase.

Als er al schema's zijn gebruikt, hebt u een aantal opties:

  • Verwijder de verouderde schemanamen en begin opnieuw.
  • Behoud de verouderde schemanamen door de naam van het verouderde schema in afwachting van de naam van de tabel in behandeling te houden.
  • Behoud de verouderde schemanamen door weergaven over de tabel te implementeren in een extra schema om de oude schemastructuur opnieuw te maken.

Notitie

Bij eerste inspectie lijkt optie 3 misschien de meest aantrekkelijke optie. De duivel zit echter in de details. Weergaven zijn alleen-lezen in een toegewezen SQL-pool. Elke wijziging van gegevens of tabellen moet worden uitgevoerd op basis van de basistabel. Optie 3 introduceert ook een laag van weergaven in uw systeem. U kunt hier wat meer over nadenken als u al weergaven in uw architectuur gebruikt.

Voorbeelden:

Door de gebruiker gedefinieerde schema's implementeren op basis van databasenamen:

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

Behoud verouderde schemanamen door ze vooraf in behandeling te laten op de tabelnaam. Gebruik schema's voor de grens van de workload:

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

Verouderde schemanamen behouden met behulp van weergaven:

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
;

Notitie

Elke wijziging in de schemastrategie vereist een beoordeling van het beveiligingsmodel voor de database. In veel gevallen kunt u het beveiligingsmodel mogelijk vereenvoudigen door machtigingen toe te wijzen op schemaniveau. Als er gedetailleerdere machtigingen zijn vereist, kunt u databaserollen gebruiken.

Volgende stappen

Zie Overzicht van ontwikkeling voor meer tips voor ontwikkeling.