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

Sou principalmente desenvolvedor de aplicativos, mas me vejo tendo que fazer todo o trabalho inicial do banco de dados para o meu projeto atual ( aliás ... o MS SQL Server 2008 ). Como primeira decisão, estou tentando descobrir se devo dividir meu estado usando bancos de dados separados ou usando 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 objetos (do que eu gosto ), mas não tenho certeza se pode haver custos ocultos nesse padrão.

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

Como uma observação lateral ... Em algum momento, isso será entregue a um DBA real para manutenção / suporte, então estou tentando garantir que não dificulte a vida deles.

Começarei dizendo não considerar esquemas como espaços para nome ou domínios de objeto 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 2 conceitos diferentes. Os dados que precisam ser consistentes transacional e referencialmente 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, encaminhá-lo-ei para perguntas anteriores, nas quais você pode ver que a opinião geral é a favor delas:

• Design de esquema - melhores práticas?
• Qual padrão devo seguir ao nomear tabelas e visualizações?
• Sobre uso / uso correto de esquemas?

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

Concorde com @gbn. Eu arquitetei soluções usando esquemas para separação e bancos de dados para separação, e acho que o uso de bancos de dados é muito mais prático. Um par de razões:

1. Ter o aplicativo conectado a um banco de dados específico do contexto e executar as mesmas consultas é muito mais fácil do que injetar suas consultas <schema>na frente de todas as referências a objetos. Isso se presta a um monte de SQL dinâmico, a vários logins de aplicativos diferentes com esquemas padrão (o que significa que seu código não usaria prefixo de esquema, contando com o esquema padrão do usuário do aplicativo - pode levar a inchaço maciç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 será alterado, agora você deverá 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 instâncias / armazenamento mais rápidas ou diferentes, sem precisar extrair objetos de um grande banco de dados abrangente. A maioria das pessoas não pensa nisso com tanta antecedência, mas é definitivamente um possível problema de escala. Especialmente se você acabar tendo um esquema que "assume" e requer a maioria dos recursos no servidor, separá-los pode ser uma tarefa extremamente complicada, mesmo se eles já estiverem separados por esquema.
3. Bancos de dados separados também podem permitir agendas de manutenção e backup diferentes para cada divisão. Não sei o que você quer dizer com "dividir por estado", mas supondo que você queira 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 com clientes que, por lei ou por 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 é insuficiente. Você pode não ter esses clientes agora, mas pode se tornar um problema real mais tarde, se você tiver.