Início / dba / Perguntas / 8511
Accepted
Stuart Blackler
Asked: 2011-11-29 16:07:30 +0800 CST

Uso excessivo/correto de esquemas?

  • 772

Tendo feito esta pergunta no Stackoverflow , me perguntei onde o que fiz é a prática correta/melhor.

Basicamente, todo objeto que eu crio vai para um esquema com o nome do esquema refletindo um uso. Por exemplo, tenho os esquemas Audite Admin(entre outros).

Isso, por sua vez, não deixa objetos em dbo. tudo bem? Existe mais alguma coisa que eu preciso fazer?

sql-server best-practices

5 respostas

  1. Best Answer

    Os esquemas não são apenas uma ótima ferramenta de segurança (o que é motivo 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, digamos que no futuro todos os objetos de banco de dados relacionados à auditoria devem ser protegidos para uma função de banco de dados. Se esses objetos estivessem espalhados por todo o dboesquema, você teria que conceder denypermissões explicitamente nos objetos individuais. Mas com o Auditesquema, você faz um único denye está pronto.

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

    • 13

  2. Um padrão típico são os 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á permitir isso, mas acabará com 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 para objetos de permissão: digamos que você tenha usuários Admin e HR Excel: todos eles executam Desktopcódigo.

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

    Algum código não é público (como um UDF ou procedimento interno), então eu usaria um Helperesquema para código que não deveria 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.

    • 5

  3. Nenhum objeto no dboesquema está perfeitamente bem. Pelo que posso ver, 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 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).

    • 4

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

    COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

    Para módulos grandes, também os separamos em 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 pelo MODULE1 , filtra por nome e trabalha quase o tempo todo apenas com essas tabelas. Isso torna muito fácil para desenvolvedores, dbas e novatos entenderem as tabelas de banco de dados.

    • 1

  5. As melhores práticas podem ser diferentes para o SQL Server e para o 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 de negócios devem ir em um esquema para que você saiba onde eles estão. As convenções de nomenclatura são suficientes para diferenciar o uso da tabela ou do código armazenado.
    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.

    • -1

relate perguntas