Vamos assumir, para fins de argumentação, que tenho as seguintes tabelas em um único banco de dados do SQL Server.
mySchema.Users
mySchema.Products
--
secondSchema.Users
secondSchema.Contracts
secondSchema.ContractItems
--
oldSchema.People
oldSchema.Table1
oldSchema.Table2
oldSchema.Table3
oldSchema.Table4
--
and so on and so forth
Cada "esquema" é totalmente independente dos outros. A única razão pela qual eles estão em um único banco de dados é devido a limitações de custo e hospedagem. Em um mundo perfeito, eles estariam em bancos de dados separados para começar.
O que precisarei fazer quando (e se for o caso) precisar mover o secondSchema para um novo banco de dados, por si só, porque seu uso aumenta e agora requer ser alojado em seu próprio banco de dados.
Analisei os critérios de decisão sobre quando usar um esquema não dbo versus um novo banco de dados e, como afirmei acima, não há justificativa relacional ou transacional para eles estarem no mesmo banco de dados. Eles estão lá por razões de custo.
Você pode fazer o script dessa parte do banco de dados e, em seguida, executar um
CREATE DATABASE
script com o esquema e os dados do banco de dados original.Ao Gerar Scripts... , você poderá selecionar objetos específicos em vez de todo o banco de dados. Você pode selecionar o esquema desejado e todos os objetos que o esquema possui . Isso gerará um script contendo seu esquema e objetos de esquema. Um pouco de operação manual, mas provavelmente o método mais fácil.
No script gerado, você pode alterar o nome do esquema para ser como o novo esquema do banco de dados deve ser chamado, mas perceba que as definições de objeto também precisam refletir o nome do novo esquema.