Schémas définis par l’utilisateur dans Synapse SQL

Dans les sections ci-dessous, vous trouverez différents conseils pour utiliser des schémas définis par l’utilisateur T-SQL pour développer des solutions dans Synapse SQL.

Schémas pour les limites d’application

L’architecture d’analytique traditionnelle utilise souvent des bases de données distinctes pour créer des limites d’application basées sur la charge de travail, le domaine ou la sécurité. Par exemple, une infrastructure d’analytique SQL Server traditionnelle peut inclure une base de données intermédiaire, une base de données d’analyse et des bases de données de data mart. Dans cette topologie, chaque base de données fonctionne comme une charge de travail et une limite de sécurité dans l’architecture.

Au lieu de cela, Synapse SQL exécute l’intégralité de la charge de travail d’analytique au sein d’une base de données. Les jointures entre bases de données ne sont pas autorisées. Synapse SQL s’attend à ce que toutes les tables utilisées par l’entrepôt soient stockées dans la base de données unique.

Remarque

Les pools SQL dédiés ne prennent pas en charge les requêtes entre bases de données d’un type quelconque. Par conséquent, les implémentations d’analyse qui tirent parti de ce modèle devront être révisées. Le pool SQL serverless prend en charge les requêtes entre bases de données.

Recommandations de schéma définies par l’utilisateur

Nous vous conseillons notamment de consolider les charges de travail, la sécurité, le domaine et les limites fonctionnelles à l’aide de schémas définis par l’utilisateur :

• Utilisez une base de données pour exécuter votre charge de travail d’analytique entière.
• Consolidez votre environnement d’analytique existant pour utiliser une base de données.
• Tirez parti des schémas définis par l’utilisateur pour fournir la limite précédemment implémentée à l’aide de bases de données.

Si les schémas définis par l’utilisateur n’ont pas été utilisés précédemment, vous partez de zéro. Utilisez l’ancien nom de base de données comme base pour vos schémas définis par l’utilisateur dans la base de données Synapse SQL.

Si des schémas ont déjà été utilisés, vous avez quelques options :

• Supprimer les noms de schémas hérités et démarrer à nouveau
• Conservez les noms de schéma hérités en faisant précéder le nom du schéma hérité au nom de la table.
• Conservez les anciens noms de schéma en implémentant des vues sur la table dans un schéma supplémentaire, ce qui reconstitue l’ancienne structure de schéma.

Remarque

Lors de la première inspection, l’option 3 peut sembler comme le choix le plus attrayant. Les affichages sont en lecture seule dans SQL Synapse. Toute modification de données ou de table doit être effectuée sur la table de base. L’option 3 introduit également une couche de vues dans votre système. Peut-être devriez-vous étudier la question plus attentivement si vous utilisez déjà des vues dans votre architecture.

Exemples

Implémentez des schémas définis par l’utilisateur en fonction des noms de base de données.

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

Conservez les noms de schéma hérités en les ajoutant au début du nom de la table. Utilisez des schémas pour la limite de charge de travail.

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

Conservez les noms de schémas hérités à l’aide de vues.

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
;

Remarque

Toute modification de la stratégie de schéma nécessite une révision du modèle de sécurité pour la base de données. Dans de nombreux cas, vous pouvez simplifier le modèle de sécurité en affectant des autorisations au niveau du schéma.

Si des autorisations plus précises sont requises, vous pouvez utiliser des rôles de base de données. Pour plus d’informations sur les rôles de base de données, consultez l’article Gérer les rôles de base de données et les utilisateurs .

Étapes suivantes

Pour obtenir des conseils supplémentaires en matière de développement, consultez Présentation du développement SQL Synapse.