Benutzerdefinierte Schemas für dedizierte SQL-Pools in Azure Synapse Analytics

Dieser Artikel konzentriert sich auf die Bereitstellung mehrerer Tipps zur Verwendung von benutzerdefinierten T-SQL-Schemas zum Entwickeln von Lösungen in dediziertem SQL-Pool.

Schemas für Anwendungsgrenzen

Herkömmliche Data Warehouses verwenden häufig separate Datenbanken, um Anwendungsgrenzen basierend auf Arbeitsauslastung, Domäne oder Sicherheit zu erstellen.

Ein herkömmliches SQL Server-Data Warehouse kann beispielsweise eine Stagingdatenbank, eine Data Warehouse-Datenbank und einige Data Mart-Datenbanken umfassen. In dieser Topologie fungiert jede Datenbank als Workload- und Sicherheitsgrenze in der Architektur.

Im Gegensatz dazu führt ein dedizierter SQL-Pool die gesamte Data Warehouse-Workload in einer Datenbank aus. Datenbankübergreifende Verknüpfungen sind nicht zulässig. Der dedizierte SQL-Pool erwartet, dass alle vom Lager verwendeten Tabellen in der 1 Datenbank gespeichert werden.

Empfehlungen

Nachfolgend werden Empfehlungen zum Konsolidieren von Workloads, Sicherheit, Domäne und funktionalen Grenzen mithilfe von benutzerdefinierten Schemas beschrieben:

• Verwenden Sie eine Datenbank in einem dedizierten SQL-Pool, um Ihre gesamte Workload im Data Warehouse auszuführen.
• Konsolidieren Sie Ihre vorhandene Data Warehouse-Umgebung, um eine dedizierte SQL-Pooldatenbank zu verwenden.
• Nutzen Sie benutzerdefinierte Schemas , um die zuvor mithilfe von Datenbanken implementierte Grenze bereitzustellen.

Wenn zuvor keine benutzerdefinierten Schemas verwendet wurden, haben Sie einen Neuanfang. Verwenden Sie den alten Datenbanknamen als Grundlage für Ihre benutzerdefinierten Schemas in der dedizierten SQL-Pooldatenbank.

Wenn Schemas bereits verwendet wurden, haben Sie einige Optionen:

• Entfernen Sie die Legacy-Schema-Namen und fangen Sie neu an.
• Behalten Sie die alten Schemanamen bei, indem Sie diese vorab an den Tabellennamen anhängen.
• Behalten Sie die älteren Schemanamen bei, indem Sie Ansichten über die Tabelle in einem zusätzlichen Schema implementieren, um die alte Schemastruktur neu zu erstellen.

Beispiele

Implementieren von benutzerdefinierten Schemas basierend auf Datenbanknamen:

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

Behalten Sie die alten Schemanamen bei, indem Sie diese vorab an den Tabellennamen anhängen. Verwenden Sie Schemas für die Workloadgrenze:

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

Behalten Sie die alten Schemanamen mithilfe von Ansichten bei:

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
;

Nächste Schritte

Weitere Hinweise zur Entwicklung finden Sie in der Entwicklungsübersicht.