Quais são algumas das práticas recomendadas para o uso de esquemas no SQL Server?

Entendo os recursos dos esquemas do SQL Server, mas quais são as práticas recomendadas? Claro que eles fornecem outra camada de segurança e fornecem um agrupamento lógico de objetos de banco de dados dentro do banco de dados, mas o que é típico lá fora? Frequentemente, na minha experiência, não vejo muitos esquemas personalizados utilizados. Isso é típico? É o cenário menos frequente em que esquemas personalizados devem ser usados?

Nos os utilizamos

• separar permissões por cliente (por exemplo, temos esquemas de área de trabalho, WebGUI etc.)
• para agrupamento lógico, por exemplo (esquemas de dados e armazenamento temporário para nossas tabelas).

Observações úteis e práticas após o white paper mencionado por Marian:

• CONCESSÃO no esquema: não há mais permissões por objeto. Portanto, um novo processo no esquema WebGUI possui automaticamente as permissões do esquema
• Agrupamentos agradáveis ​​no SSMS Object Explorer
• OBJECT_SCHEMA_NAME
• Você é forçado a qualificar nomes de objetos (o que é uma prática recomendada)

Eu acho que uma resposta pode ser encontrada neste artigo do MSDN: Práticas recomendadas do SQL Server - Implementação de esquemas de objetos de banco de dados .

Citação: "Este white paper discute as oportunidades de aprimoramentos na administração de segurança de um banco de dados do usuário e descreve algumas práticas recomendadas ao usar esquemas para gerenciar objetos de banco de dados em bancos de dados de desenvolvimento e produção. Especificamente, ele aborda três cenários do mundo real:

• Protegendo objetos do banco de dados contra alterações pelos usuários sem o conhecimento do proprietário do banco de dados
• Impedindo que os objetos base do banco de dados, bancos de dados ISV (fornecedor independente de software independente) em particular, acessem ad hoc ou incorretamente o usuário, levando a um desempenho ruim do aplicativo
• Reunindo grupos de objetos relacionados (entidades lógicas) em um único banco de dados físico para reduzir a sobrecarga administrativa do banco de dados físico ".

Utilizo especialmente a terceira parte - relaciono o grupo de objetos com base em seu significado lógico - esquemas diferentes pertencentes a diferentes projetos dentro do mesmo banco de dados.

Você pode ir a alguns dos textos fundamentais sobre o assunto para abordar algumas de suas perguntas. Os documentos sobre o modelo de banco de dados relacional da EF Codd e CJ Date abordam muitas questões comuns relacionadas a design, desempenho, segurança, design ideal de esquemas etc. Por fim, como pais do modelo moderno de banco de dados relacional, seus trabalhos são a base do DB2, ORACLE, SQL Server (Microsoft e Sybase), Ingres, MySQL e qualquer outra solução de banco de dados relacional disponível.