Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Este artículo se centra en proporcionar varias sugerencias para usar esquemas definidos por el usuario de T-SQL para desarrollar soluciones en un grupo de SQL dedicado.
Esquemas para los límites de la aplicación
Los almacenes de datos tradicionales suelen usar bases de datos independientes para crear límites de aplicación basados en cargas de trabajo, dominio o seguridad.
Por ejemplo, un almacenamiento de datos de SQL Server tradicional podría incluir una base de datos de almacenamiento provisional, una base de datos de almacenamiento de datos y algunas bases de datos de data mart. En esta topología, cada base de datos funciona como un límite de carga de trabajo y seguridad en la arquitectura.
Por el contrario, un grupo de SQL dedicado ejecuta toda la carga de trabajo de almacenamiento de datos dentro de una base de datos. No se permiten combinaciones entre bases de datos. El grupo de SQL dedicado espera que todas las tablas usadas por el almacén de datos se almacenen dentro de una única base de datos.
Nota:
El grupo de SQL no admite consultas entre bases de datos de ningún tipo. Por lo tanto, las implementaciones de almacenamiento de datos que aprovechan este patrón deberán revisarse.
Recomendaciones
A continuación se muestran recomendaciones para consolidar cargas de trabajo, seguridad, dominio y límites funcionales mediante esquemas definidos por el usuario:
- Use una base de datos en un grupo de SQL dedicado para ejecutar toda la carga de trabajo del almacenamiento de datos.
- Consolide el entorno de almacenamiento de datos existente para usar una base de datos de grupo de SQL dedicada.
- Aproveche los esquemas definidos por el usuario para proporcionar el límite implementado previamente mediante bases de datos.
Si los esquemas definidos por el usuario no se han usado anteriormente, tiene la oportunidad de partir de cero. Use el nombre de la base de datos anterior como base para los esquemas definidos por el usuario en la base de datos del grupo de SQL dedicado.
Si ya se han usado esquemas, tiene algunas opciones:
- Quite los nombres de esquema heredados y comience de nuevo.
- Conserve los nombres de esquema heredados anteponiendo el nombre del esquema heredado al nombre de la tabla.
- Conserve los nombres de esquema heredados mediante la implementación de vistas sobre la tabla en un esquema adicional para volver a crear la estructura de esquema anterior.
Nota:
A primera vista, la opción 3 puede parecer la más atractiva. Sin embargo, el diablo está en el detalle. Las vistas son de solo lectura en el grupo de SQL dedicado. Cualquier modificación de datos o tabla tendría que realizarse en la tabla base. La opción 3 también introduce una capa de vistas en tu sistema. Es posible que quiera darle un pensamiento adicional si ya usa vistas en la arquitectura.
Ejemplos:
Implemente 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 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
, ...
);
Mantenga los nombres de esquema heredados anteponiendolos al nombre de la tabla. Use esquemas para el límite de la carga de trabajo:
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
, ...
);
Conservar los nombres de esquemas heredados con vistas:
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
;
Nota:
Cualquier cambio en la estrategia de esquema necesita una revisión del modelo de seguridad de la base de datos. En muchos casos, es posible que pueda simplificar el modelo de seguridad asignando permisos en el nivel de esquema. Si se requieren permisos más pormenorizados, puede usar roles de base de datos.
Pasos siguientes
Para obtener más sugerencias sobre desarrollo, vea la información general sobre desarrollo.