¿Cuáles son algunas de las mejores prácticas para usar esquemas en SQL Server?

Entiendo las capacidades de los esquemas de SQL Server, pero ¿cuáles son las mejores prácticas? Claro que brindan otra capa de seguridad y proporcionan una agrupación lógica de objetos de base de datos dentro de la base de datos, pero ¿qué es lo típico? A menudo, en mi experiencia, no veo muchos esquemas personalizados utilizados. ¿Es esto típico? ¿Es el escenario menos frecuente donde se deben usar esquemas personalizados?

Nosotros los usamos

• para separar los permisos por cliente (por ejemplo, tenemos esquemas de escritorio, WebGUI, etc.)
• para la agrupación lógica, por ejemplo (esquemas de datos y etapas para nuestras tablas).

Observaciones útiles y prácticas más allá del libro blanco mencionado por Marian:

• CONCESIÓN en el esquema: no más permisos por objeto. Entonces, un nuevo proceso en el esquema WebGUI tiene automáticamente los permisos del esquema
• Agrupaciones agradables en SSMS Object Explorer
• OBJECT_SCHEMA_NAME
• Usted está obligado a calificar los nombres de los objetos (que es la mejor práctica)

Creo que se puede encontrar una respuesta en este artículo de MSDN: SQL Server Best Practices - Implementation of Database Object Schemas .

Cita: "Este documento técnico analiza las oportunidades de mejoras en la administración de seguridad de una base de datos de usuarios, y describe algunas de las mejores prácticas sobre el uso de esquemas para administrar objetos de bases de datos en bases de datos de desarrollo y producción. Específicamente, aborda tres escenarios del mundo real:

• Proteger los objetos de la base de datos para que no sean alterados por los usuarios sin el conocimiento del propietario de la base de datos.
• Prevención de los objetos base de la base de datos, en particular las bases de datos de proveedores de software independientes (ISV), desde el acceso ad hoc o incorrecto del usuario que conduce a un bajo rendimiento de la aplicación
• Reunir grupos de objetos relacionados (entidades lógicas) dentro de una base de datos física para reducir la sobrecarga administrativa de la base de datos física ".

Especialmente utilizo la tercera parte, relacionar un grupo de objetos en función de su significado lógico, diferentes esquemas que pertenecen a diferentes proyectos dentro de la misma base de datos.

Es posible que desee ir a algunos de los textos fundamentales sobre esto para abordar algunas de sus preguntas. Los documentos sobre el modelo de base de datos relacional de EF Codd y CJ Date abordan muchas preguntas comunes relacionadas con el diseño, el rendimiento, la seguridad, el diseño de esquema óptimo, etc. En última instancia, como padres del modelo moderno de base de datos relacional, sus trabajos son la base de DB2, ORACLE, SQL Server (Microsoft y Sybase), Ingres, MySQL y todos los demás conjuntos de soluciones de bases de datos relacionales disponibles.