Sobre uso / uso correto de esquemas?

Depois de fazer esta pergunta no Stackoverflow , perguntei-me onde o que fiz foi a correta / melhor prática.

Basicamente, todo objeto que eu criei está entrando em um esquema com o nome do esquema refletindo um uso. Por exemplo, eu tenho os esquemas Audite Admin(entre outros).

Por sua vez, não deixa objetos dentro dbo. Tudo bem? Preciso fazer mais alguma coisa?

Os esquemas não são apenas uma ótima ferramenta de segurança (razão suficiente para usá-los), mas também são perfeitos para a separação lógica. E parece que é isso que você está praticando.

Mesmo que o requisito atual não precise de segurança especial, diga a seguir que todos os objetos de banco de dados relacionados à Auditoria devem estar seguros para uma função de banco de dados. Se esses objetos estiverem espalhados por todo o dboesquema, você precisará ter denypermissões explícitas nos objetos individuais. Mas com o Auditesquema, você faz um single denye está pronto.

Eu pessoalmente pratico o uso de esquemas. Como todas as coisas nos bancos de dados, porém, existe um meio feliz. Eu não criaria um esquema para cada aspecto granular da camada de dados. Existem muitos esquemas e separação. Mas acho que você não está nem perto disso.

Um padrão típico é esquemas baseados em permissões, portanto, você teria WebGUI, Desktopetc , para código, para que todos os objetos tenham as mesmas permissões do esquema .

Se você tiver grupos de usuários claros, poderá obter permissão, mas você terá permissões sobrepostas e confusas em algum momento. Costumo adiar as verificações de usuário / grupo para algumas verificações dentro do código e não de objetos de permissão: digamos que você tenha usuários de Admin e RH do Excel: todos eles executam Desktopcódigo.

Os dados geralmente são compartilhados, então eu teria um Dataesquema, talvez um Historyou Archiveesquema.

Como algum código não é público (como um UDF ou um processo interno), use um Helperesquema para código que não deve ser executado pelo código do cliente.

Finalmente, esquemas como Stagingou Systemou Maintenancesão úteis às vezes.

Embora não haja objetos de usuário no dboesquema, o usuário dbopossui todos os esquemas.

Nenhum objeto no dboesquema está perfeitamente correto. Pelo que pude ver, isso também não é uso excessivo de esquemas - embora quantos esquemas sejam 'demais' seja uma questão bastante subjetiva (é comparável a "Quantas classes meu design de OO deve ter?").

A única outra coisa que eu mencionaria seria conceder permissões no esquema em vez de objetos individuais (sua pergunta SO não especifica nada sobre permissões).

Eu gostaria de usar esquemas para separar o banco de dados de acordo com os módulos e padrões de uso. Acho que facilita a compreensão das tabelas do banco de dados, portanto, a manutenção se torna mais fácil. Eu tinha os seguintes tipos de esquema no meu último projeto de servidor sql. LT - Tabelas de pesquisa

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Para grandes módulos, também os separamos para mais esquemas. Por exemplo, o módulo pessoal consiste em mais de 5 módulos.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Também incluímos esquemas como para outras atividades TEMP, MANUTENÇÃO. No estúdio de gerenciamento, você pode filtrar usando o nome do esquema. Um desenvolvedor responsável por MODULE1, filtra de acordo com o nome e trabalha quase o tempo todo apenas com essas tabelas. Isso torna muito fácil para desenvolvedores, dbas e novatos entenderem as tabelas do banco de dados.

As práticas recomendadas podem ser diferentes para o servidor sql e para a Oracle, no entanto, minha experiência é que quanto menos esquemas, melhor.
Eu gosto de ter um esquema para o dba / programmer que tenha privilégios especiais e algum código para fazer manutenção. Todos os dados comerciais devem entrar em um esquema para que você saiba onde estão. As convenções de nomenclatura são suficientes para diferenciar entre o uso da tabela ou o código armazenado.
Eu posso ver um caso em que você tem várias unidades de negócios devido a dados diferentes com pouca sobreposição, cada uma com seu próprio esquema. Caso contrário, mantenha-o simples.