Início / dba / Perguntas / 11101
Accepted
JoeGeeky
Asked: 2012-01-22 03:31:41 +0800 CST

Critérios de decisão sobre quando usar um esquema não dbo versus um novo banco de dados

  • 772

Sou principalmente um desenvolvedor de aplicativos, mas tenho que fazer todo o trabalho de banco de dados inicial para meu projeto atual ( aliás ... é MS SQL Server 2008 ). Como primeira decisão, estou tentando descobrir se devo dividir meu estado usando bancos de dados separados ou esquemas separados no mesmo banco de dados. Eu fiz uma pequena leitura no esquema do SQL Server e parece uma maneira natural de separar domínios de objeto ( que eu gosto ), mas não tenho certeza se pode haver custos ocultos para esse padrão.

Quais são as coisas mais práticas que devo considerar ao selecionar entre essas duas abordagens? Se eu evitar o dbo.mytablefavor de myschema.mytableestarei criando outros desafios ( ou problemas ) para minha arquitetura?

Como uma observação lateral... Em algum momento, isso será entregue a um DBA real para manter/suportar, então estou tentando ter certeza de não tornar a vida deles mais difícil.

sql-server-2008 database-design

2 respostas

  1. Best Answer

    Começarei dizendo para não considerar esquemas como namespaces ou domínios de objetos no sentido OO. Os esquemas são essencialmente contêineres de permissão com algum valor agregado (veja abaixo)

    Além disso, "esquemas separados" ou "bancos de dados separados" são dois conceitos diferentes. Os dados que precisam ser transacionalmente e referencialmente consistentes precisam estar no mesmo banco de dados. Veja um banco de dados ou dez? artigo do blog para mais.

    Nesse banco de dados, você pode ou não usar esquemas para organizar seus objetos.

    Pessoalmente, sou fã de esquemas e sempre os uso, mas para coisas como permissões e agrupamento lógico. Para isso, remeto-vos às questões anteriores onde podem ver que a opinião geral é favorável às mesmas:

    Para o caso de bancos de dados separados, consulte a resposta de Aaron , mas tudo isso depende do requisito "transacionalmente e referencialmente consistente".

    • 17

  2. Concordo com @gbn. Arquitetei soluções usando esquemas para separação e bancos de dados para separação e acho que usar bancos de dados é muito mais prático. Algumas razões:

    1. Ter seu aplicativo conectado a um banco de dados específico do contexto e, em seguida, executar as mesmas consultas é muito mais fácil do que injetar suas consultas <schema>na frente de todas as referências de objeto. Isso se presta a muito SQL dinâmico, muitos logins de aplicativos diferentes com esquemas padrão (o que significa que seu código não usaria o prefixo do esquema, contando com o esquema padrão do usuário do aplicativo - pode levar a um enorme inchaço do cache do plano e depuração difícil), ou muitos procedimentos armazenados para gerenciar (imagine apenas um relatório simples, se você precisar de um por esquema, o código muda, agora você precisa alterar o mesmo código várias vezes, uma vez para cada esquema).
    2. A separação por banco de dados permite a flexibilidade de mover bancos de dados ocupados para armazenamentos/instâncias mais rápidos ou diferentes sem ter que extrair objetos de um grande banco de dados abrangente. A maioria das pessoas não pensa nisso com tanta antecedência, mas é definitivamente um problema de escala em potencial. Principalmente se você acabar tendo um esquema que "assume o controle" e requer a maior parte dos recursos do servidor, dividi-los pode ser uma tarefa extremamente complicada, mesmo que já estejam separados por esquema.
    3. Bancos de dados separados também podem permitir que você tenha diferentes cronogramas de manutenção e backup para cada divisão. Não tenho certeza do que você quer dizer com "dividir por estado", mas supondo que você queira dizer isolar clientes, você pode ter clientes com requisitos diferentes e tolerância diferente para perda de dados, manutenção de índice, etc.
    4. Você pode acabar tendo clientes que, por lei ou política corporativa, precisam que você mantenha seus dados separados de qualquer outra pessoa. Isso geralmente é aceitável no nível do banco de dados, mas o nível do esquema geralmente será insuficiente. Você pode não ter esses clientes agora, mas pode se tornar um problema real mais tarde se você o fizer.
    • 11

relate perguntas