Existem desvantagens em bancos de dados contidos?

O objetivo principal dos bancos de dados contidos é facilitar a portabilidade de seu banco de dados para um novo servidor sem muitos andaimes em torno dele. Com isso em mente, tratarei de alguns possíveis problemas que tornarão essa migração mais difícil - e a maioria gira em torno do fato de que os bancos de dados contidos estão apenas parcialmente contidos no SQL Server 2012 (a contenção não é realmente aplicada).

Cadeias de conexão

As strings de conexão para um banco de dados contido devem especificar explicitamente o banco de dados na string de conexão. Você não pode mais confiar no banco de dados padrão de login para estabelecer uma conexão; se você não especificar um banco de dados, o SQL Server não percorrerá todos os bancos de dados contidos e tentará localizar qualquer banco de dados em que suas credenciais possam corresponder.

Consultas entre bancos de dados

Mesmo se você criar o mesmo usuário com a mesma senha em dois bancos de dados contidos diferentes no mesmo servidor, seu aplicativo não poderá realizar consultas entre bancos de dados. Os nomes de usuário e senhas podem ser os mesmos, mas não são o mesmo usuário. A razão para isso? Se você tiver bancos de dados contidos em um servidor hospedado, não deverá ser impedido de ter o mesmo usuário contido de outra pessoa que esteja usando o mesmo servidor hospedado. Quando chega a contenção total (provavelmente na versão após o SQL Server 2012 nunca), as consultas entre bancos de dados serão absolutamente proibidas de qualquer maneira. Eu altamente, altamente, altamente recomendável que você não crie logins no nível do servidor com o mesmo nome dos usuários do banco de dados independente e tente evitar criar o mesmo nome de usuário independente em bancos de dados independentes. Se você precisar executar consultas que atinjam vários bancos de dados contidos, faça-o usando um login no nível do servidor que tenha privilégios apropriados (você pode pensar que é sysadmin, mas para consultas somente leitura, é CONNECT ANY DATABASEe SELECT ALL USER SECURABLES).

sinônimos

A maioria dos nomes de 3 e 4 partes são fáceis de identificar e aparecem em um DMV. No entanto, se você criar um sinônimo que aponte para um nome de 3 ou 4 partes, eles não aparecerão no DMV. Portanto, se você fizer uso intenso de sinônimos, é possível que perca algumas dependências externas, e isso pode causar problemas no momento de migrar o banco de dados para outro servidor. Reclamei sobre esse problema, mas ele foi fechado como "por design" e não sobreviveu à migração para o novo sistema de feedback . Observe que o DMV também perderá nomes de 3 e 4 partes que são construídos por meio de SQL dinâmico.

política de senha

Se você criou um usuário de banco de dados independente em um sistema sem uma política de senha em vigor, pode achar difícil criar o mesmo usuário em um sistema diferente que tenha uma política de senha em vigor. Isso ocorre porque a CREATE USERsintaxe não oferece suporte para ignorar a política de senha. Eu registrei um bug sobre esse problema e ele permanece aberto (e também não sobreviveu à mudança quando o Connect foi desativado). E parece estranho para mim que em um sistema com uma política de senha em vigor, você pode criar um login no nível do servidor que ignora facilmente a política, mas não pode criar um usuário de banco de dados que faça isso - mesmo que esse usuário seja inerentemente menos de um risco de segurança.

Agrupamento

Como não podemos mais confiar no agrupamento de tempdb, talvez seja necessário alterar qualquer código que atualmente usa agrupamento explícito ou DATABASE_DEFAULTusar CATALOG_DEFAULTem vez disso. Veja este artigo BOL para alguns problemas potenciais .

IntelliSense

Se você se conectar a um banco de dados independente como um usuário independente, o SSMS não dará suporte total ao IntelliSense. Você obterá sublinhado básico para erros de sintaxe, mas nenhuma lista de preenchimento automático ou dicas de ferramentas e todas as coisas divertidas. Eu registrei um bug sobre esse problema e ele permanece aberto - e mais um que não sobreviveu à mudança.

Ferramentas de dados do SQL Server

Se você planeja usar SSDT para desenvolvimento de banco de dados, atualmente não há suporte completo para bancos de dados independentes. O que realmente significa apenas que a construção do projeto não falhará se você usar algum recurso ou sintaxe que quebre a contenção, já que o SSDT atualmente não sabe o que é contenção e o que pode quebrá-la.

ALTER DATABASE

Ao executar um ALTER DATABASEcomando de dentro do contexto de um banco de dados contido, rEm vez de ALTER DATABASE foovocê precisar usar ALTER DATABASE CURRENT- isso é para que, se o banco de dados for movido, renomeado etc., esses comandos não precisam saber nada sobre seu contexto externo ou referência .

alguns outros

Algumas coisas que você provavelmente ainda não deveria estar usando, mas mesmo assim devem ser mencionadas na lista de coisas que não são suportadas ou estão obsoletas e não devem ser usadas em bancos de dados contidos:

• procedimentos numerados
• procedimentos temporários
• alterações de agrupamento em objetos vinculados
• alterar captura de dados
• rastreamento de mudanças
• replicação

Dito isso, essas não são necessariamente desvantagens do uso de bancos de dados contidos, são apenas problemas dos quais você deve estar ciente e nem todos são explicitamente divulgados na documentação oficial.

Você também precisará ter certeza de que, se um banco de dados contido for migrado, fizer parte de um grupo de disponibilidade ou estiver sendo espelhado, todos os servidores de destino em potencial terão a sp_configureopção contained database authenticationdefinida como 1.

Você pode achar esta postagem de blog útil, assim como esta , mesmo que sejam anteriores ao RTM.

Para aqueles que estão interessados ​​em obter mais detalhes sobre bancos de dados contidos, recomendo a leitura deste artigo http://www.sqlshack.com/contained-databases-in-sql-server/

O artigo aponta as principais vantagens/desvantagens do uso de bancos de dados contidos.

Desvantagens

Bancos de dados parcialmente contidos não podem usar recursos como replicação, captura de dados alterados, controle de alterações, objetos associados a esquemas que dependem de funções integradas com alterações de agrupamento.

Vantagens

Por outro lado, como já mencionado, existem alguns benefícios do uso de BDs contidos, como:

• É muito fácil mover o banco de dados de um servidor para outro,
  pois não haverá problemas de usuários órfãos
• Os metadados são armazenados em bancos de dados contidos, por isso é mais fácil e portátil
• É possível ter autenticação do SQL Server e do Windows para usuários de banco de dados contidos

O artigo também ajuda com:

• criando um novo banco de dados contido (tornando o tipo de contenção como Parcial na página Opções no SQL Server e usando a consulta T-SQL para criar um banco de dados posteriormente)
• conectando-se ao banco de dados contido usando o SQL Server Management Studio (é necessário especificar o nome do banco de dados contido no parâmetro de conexão)
• convertendo banco de dados existente em um banco de dados independente
• trabalhando em um banco de dados independente e listando todos os logins que são do tipo de usuário independente

Uma desvantagem é que um usuário de banco de dados contido não pode ser forçado a alterar sua própria senha, como os logins ( MUST_CHANGE). Os usuários não podem gerenciar suas próprias senhas, a menos que você conceda a eles uma permissão de alteração de usuário e diga a eles como alterá-la usando uma instrução SQL. Não é fácil para eles gerenciá-lo por meio de interfaces de usuário ou pelo menos não sei como.

Observação adicional é que encontrei o uso de metadados inesperado e não documentado na cláusula "PIVOT" E "UNPIVOT" que pensei que deveria estar apenas no catálogo do sistema (sys.tables/sys.columns/etc). Conforme documentado no msdn :

Em um banco de dados contido, o agrupamento de catálogo Latin1_General_100_CI_AS_WS_KS_SC . Esse agrupamento é o mesmo para todos os bancos de dados contidos em todas as instâncias do SQL Server e não pode ser alterado.

Mas eles não mencionaram que a cláusula "PIVOT" AND "UNPIVOT" também usa os catálogos do sistema como mecanismo de execução. portanto, produz um erro de conflito de agrupamento em todos os lugares perto do uso da cláusula "PIVOT" E "UNPIVOT" durante a migração. aqui está alguma reprodução:

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

você também pode ver que os artigos sobre banco de dados contidos estão incompletos. então decidir usá-lo requer uma improvisação muito boa.