Mejores prácticas para usar esquemas en SQL Server (2008)

Question

Veo en la base de datos de AdventureWorks que se usan diferentes esquemas para agrupar tablas. ¿Por qué se hace esto (seguridad, ...?) Y ¿hay mejores prácticas que pueda encontrar?

THX, Lieven Cardoen

Answer 1

Como gerente de Inteligencia de Negocios, que se basan en el esquema de agrupación lógica y la gestión de la seguridad. Aquí hay algunos casos en cuanto a cómo usamos esquema:

organización lógica

1. Tenemos una base de datos general que se carga por paquetes SSIS únicamente para los datos de estadificación antes cargamos nuestro almacén de datos operativos (ODS) En esta base de datos, a excepción del esquema, todos los objetos tienen una estructura idéntica (nombres de tabla, nombres de columna, tipos de datos, capacidad de anulación, etc.) a su fuente original. Usamos el esquema para indicar el sistema fuente original de la tabla. En algunos casos excepcionales, dos bases de datos diferentes tienen tablas con el mismo nombre y el esquema nos permite continuar utilizando el nombre original en la base de datos provisional.

2. En cada base de datos en nuestros servidores BI, cada miembro del equipo tiene un esquema test_username. Cuando creamos objetos de prueba en una base de datos, esto facilita el seguimiento de quién hizo el objeto. También hace que sea mucho más fácil purgar los objetos de prueba más tarde ya que todos saben quién hizo qué. Francamente, el solo hecho de saber que lo logramos es suficiente para saber que se puede eliminar de manera segura, especialmente cuando no podemos recordar cuándo o por qué lo logramos.

3. En nuestra base de datos de controladores de datos, confiamos en el esquema para separar diferentes tipos de procesos entre informes, etl y recursos genéricos.

4. En nuestro almacén de datos de esquema de estrella, todos los objetos se dividen en esquemas de dimensiones y hechos.

5. Cuando enviamos datos a otros servidores departamentales, hacemos que todos los objetos BI en sus servidores utilicen el esquema bi. Esto hace REALMENTE fácil saber las cargas bi y mantiene la tabla aunque no esté en nuestro servidor. Si el servidor de destino no es un cuadro de SQL Server 2008/2005, prefijamos la tabla con bi_.

Cuando se llega a esto, se utiliza el esquema de organización lógica en cualquier momento que habría anexado un prefijo o sufijo a un objeto para ayudar a organizar en la ausencia de esquema. Habiendo dicho esto, hay algunas instancias en las que no utilizamos el esquema en nuestros servidores de BI. En nuestro WorkingDB, todo es dbo. Nuestro WorkingDB se usa como TempDB para crear tablas temporales, pero estas tablas son temporales que sabemos que crearemos cada vez que se ejecute un proceso ETL. La propiedad especial de WorkingDB es que nunca respaldamos la base de datos y todos los procesos ETL que usan la base de datos deben poder volver a crear sus objetos desde cero en ausencia de la tabla. En este caso, sentimos que el uso de schema no agrega NINGÚN valor organizacional ya que en realidad no usamos los objetos fuera de su proceso ETL temporal.

SEGURIDAD

1. Puesto que somos un grupo de BI, que generalmente no construir y apoyar nuestras propias aplicaciones. Utilizamos casi exclusivamente las aplicaciones de otras personas y traemos datos de sus bases de datos back-end a nuestro servidor. Sin embargo, tenemos una base de datos llamada bi_applications que es el back-end para una variedad de pequeñas aplicaciones CRUD.Estas aplicaciones generalmente son formularios de ingreso de datos que le proporcionamos a la empresa para que puedan capturar datos que de otra manera tendríamos que mantener en BI. Es una forma de obtener datos que deberían estar en aplicaciones de producción en BI mientras esperamos que nuestras mejoras de baja prioridad apliquen polvo en las futuras listas de desarrollo. Cada aplicación tiene un esquema separado y la cuenta de la aplicación utilizada para actualizar las tablas subyacentes SOLO tiene acceso a los objetos del esquema asociado. Esto hace que sea realmente fácil de entender, asegurar y mantener las aplicaciones por separado.

2. En algunos casos, he permitido que los usuarios avanzados tengan acceso directo a la base de datos a nuestras tablas o procedimientos almacenados. Confiamos en el uso de un esquema combinado con roles para asegurar los objetos. Otorgamos permisos al esquema y los usuarios se agregan a los roles. Esto nos permite comprender fácilmente qué objetos utiliza quien sin tener que buscar los roles para resolverlo.

En resumen, se utiliza el esquema por motivos de seguridad, cuando, probablemente habría considerado que separa los objetos fuera en sus propias bases de datos y cuando esperamos una aplicación o usuario fuera de BI para acceder a nuestras bases de datos.

Aunque estas no son las mejores prácticas comerciales para los desarrolladores de aplicaciones, espero que mis casos de uso bi puedan ayudarlo a pensar en algunas de las formas de usar el esquema en su parte final del negocio.