Esquemas definidos por el usuario en SQL de Synapse

En las secciones siguientes encontrará varias sugerencias sobre el uso de esquemas definidos por el usuario de T-SQL para desarrollar soluciones en SQL de Synapse.

Esquemas para los límites de la aplicación

La arquitectura de análisis tradicional suele usar bases de datos independientes para crear los límites de la aplicación en función de la carga de trabajo, el dominio o la seguridad. Por ejemplo, una arquitectura de análisis de SQL Server tradicional podría incluir una base de datos provisional, una base de datos de análisis y algunas bases de datos data mart. En esta topología, cada base de datos funciona como una carga de trabajo y límite de seguridad de la arquitectura.

En su lugar, SQL de Synapse ejecuta toda la carga de trabajo de análisis en una base de datos. No se permiten las combinaciones entre bases de datos. SQL de Synapse espera que todas las tablas usadas por el almacenamiento se almacenen en una sola base de datos.

Nota:

Los grupos de SQL dedicados no admiten ningún tipo de consulta entre bases de datos. En consecuencia, deben revisarse las implementaciones de análisis que utilizan este patrón. Un grupo de SQL sin servidor admite las consultas entre bases de datos.

Recomendaciones para esquemas definidos por el usuario

Se incluyen recomendaciones para consolidar los límites de cargas de trabajo, seguridad, dominios y funcionalidad con esquemas definidos por el usuario:

• Use una base de datos para ejecutar toda la carga de trabajo de análisis.
• Consolide el entorno de análisis actual para usar una base de datos.
• Utilice esquemas definidos por el usuario para proporcionar el límite implementado anteriormente con las bases de datos.

Si anteriormente no se han usado los esquemas definidos por el usuario, comenzará desde cero. Use el nombre de la base de datos anterior como punto de partida para los esquemas definidos por el usuario en la base de datos de SQL de Synapse.

Si ya se han usado los esquemas, tiene algunas opciones:

• Quitar los nombres de esquemas heredados y empezar desde cero.
• Conservar los nombres de esquemas heredados al anteponer el nombre del esquema heredado al nombre de la tabla.
• Conservar los nombres de esquemas heredados mediante la implementación de vistas sobre la tabla en un esquema adicional, de modo que se vuelve a crear la estructura del esquema anterior.

Nota

En la primera inspección, la opción 3 puede resultar la más atractiva. Las vistas son de solo lectura en SQL de Synapse. Cualquier modificación de datos o tablas tendría que realizarse según la tabla de base. La opción 3 también introduce una capa de vistas en el sistema. Debería considerar esta opción si ya usa vistas en la arquitectura.

Ejemplos

Implementar los esquemas definidos por el usuario en función de los nombres de base de datos.

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

Mantener los nombres de los esquemas heredados al anteponerlos al nombre de la tabla. Utilizar esquemas para el límite de carga de trabajo.

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

Conservar los nombres de los esquemas heredados mediante vistas.

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
;

Nota

Cualquier cambio en la estrategia de esquema requiere de una revisión del modelo de seguridad de la base de datos. En muchos casos puede simplificar el modelo de seguridad mediante la asignación de permisos a nivel de esquema.

Si se requieren permisos más específicos, puede usar los roles de base de datos. Para obtener más información acerca de los roles de base de datos, consulte Administración de usuarios y roles de base de datos.

Pasos siguientes

Para obtener más sugerencias sobre desarrollo, consulte la información general sobre desarrollo de SQL de Synapse.