Servidor SQL: convenciones para asignar un nombre a un esquema

Question

Considere un servidor de base de datos cuyo trabajo hoy es albergar una base de datos. Es probable que la base de datos se traslade en el futuro a otra instancia de base de datos que contenga múltiples bases de datos & esquemas.

Imaginemos que la aplicación/proyecto se llama Invoicer 2.0. La base de datos se llama AcmeInvoice. La base de datos contiene toda la factura, el cliente y la información del producto. Aquí hay un diagrama de los actores y sus roles y comportamiento.

El esquema (s) será en gran parte se utiliza para asignar fácilmente permisos a roles. El beneficio adicional aquí es que los objetos no están bajo dbo, y que los permisos de los objetos & pueden transferirse a otra máquina en el futuro.

Pregunta

• Lo convenciones Cómo se utiliza cuando nombrar el esquema?
• ¿Es buena forma nombrar el esquema igual que la base de datos?

Answer 1

Creo que si el nombre de su esquema termina siendo el mismo que el esquema de su base de datos, entonces solo está agregando redundancia a su base de datos. Busque objetos en su base de datos que tengan un alcance o propósito común y cree un esquema para reflejar ese alcance. Entonces, por ejemplo, si tiene una entidad para Facturas, y tiene algunas tablas de búsqueda de apoyo para estados de factura, etc., luego colóquelas todas en un esquema de factura.

Como norma general, trataría de evitar usar un nombre que refleje el nombre de la aplicación, el nombre de la base de datos u otras cosas concretas/físicas porque pueden cambiar, y encontrar un nombre que represente conceptualmente el alcance de sus objetos eso irá al esquema.

Su comentario indica que "los esquemas se usarán en gran medida para asignar fácilmente permisos a los roles". El diagrama muestra los tipos de usuarios específicos que tienen acceso a algunas/todas las tablas o algunos/todos los procesos almacenados. Creo que tratar de organizar objetos conceptualmente en esquemas y organizarlos desde un punto de vista de seguridad en esquemas son cosas contradictorias. Estoy a favor de crear roles en el servidor sql para reflejar los tipos de usuarios y otorgarles a esos roles acceso a los objetos específicos que cada tipo de usuario necesita, ya que están dispuestos a otorgarle al rol o al usuario acceso al esquema para construir su marco de seguridad.

Answer 2

¿Por qué nombre el esquema igual que la base de datos? Esto significa que todos los objetos de la base de datos se encuentran bajo el mismo esquema. Si este es el caso, ¿por qué tener un esquema?

Normalmente, los esquemas se utilizan para agrupar objetos dentro de un ámbito común de actividad o función. Por ejemplo, dado lo que ha descrito, puede tener un esquema de Factura, un esquema de Cliente y un esquema de Producto. Todos los objetos relacionados con la factura entrarían en el esquema de la factura, todos los objetos relacionados con el cliente irían al esquema del cliente, y lo mismo para los productos.

A menudo usaremos también un esquema común que incluye objetos que pueden ser comunes a toda nuestra aplicación.

Answer 3

Me gustaría llamar a la base de datos AcmeInvoice (u otro nombre adecuado) y al esquema Invoicer2.

Mis motivos son los siguientes: Acmeinvoice significa que estoy agrupando todos los objetos/datos de las aplicaciones juntos. Por lo tanto, se puede mover como una unidad a otras máquinas (una copia de seguridad/restaurar o untar/adjuntar).

El esquema sería Invoicer2. Las aplicaciones cambian, quizás en el futuro tenga Invoicer21 (usted crearía un esquema), o tal vez un módulo o sistema de informes (esquema de Informes). El uso de esquemas me permite separar datos/procedimientos en una base de datos en diferentes grupos que facilitan la administración de permisos.