从一个存在的库，抽取其表结构，对象，权限等，再部署成一个不包含数据的”空库“的方法有很多种。如自带的Generate Scripts功能，自定义脚本提取创建脚本等。
在实际使用中，我更喜欢使用DAC的方式。特别是它能跟PowerShell结合使用。
什么是DAC，它能干什么？
数据层应用程序 (DAC) 可以简化支持客户端-服务器或多层应用程序的数据层元素的开发、部署和管理。每个 DAC 都作为单个管理单元运行，贯穿于关联应用程序的开发、测试和生产生命周期。DAC 定义支持应用程序所需的所有数据库对象（如表和视图）以及与数据库关联的实例对象（例如登录名）。DAC 还包括用于定义 DAC 的部署先决条件的策略。
它能实现的功能很，官方说明：数据层应用程序
下面简单介绍一下利用DAC迁移数据结构的步骤：
1. 创建测试库和登录。然后提取库为DAC包，这个过程有向导，很简单，基本一路Next。
use master go create database DAC_Test go create login DAC_User with password='P@ssword123' go use DAC_Test go select * into tb1 from sys.objects select * into tb2 from sys.objects go create user DAC_User for login DAC_User exec sp_addrolemember 'db_owner','DAC_User' go
2. Application name需要注意，后面会用到。
3. 提取DAC并不是所有对象都受支持，支持类型限制在BOL中有说明。我曾经就遇到过数据库有Synonyms不能提取，只能先删除之，再提取。
然后一路Next，得到一个生成的DAC包。
4. 在目标实例上创建一个空库，不一定要同名。首先将这个库注册成DAC。
5. 注册的Application name要与2.中的一致。
6. 注册成功后， 在Management—>Data-tier Application会看到此DAC。
7. 将前面生成DAC包，拷到一个目标实例上能访问的位置。然后使用Upgrade Data-tier Application将这个包导入。一路Next.
8. 完成后，源库中的各种对象都有了。有一点要注意，目标实例被导入的Login是被禁用的，并且在目标库上对应User的Role,并不是原来的db_owner,而是public。
需要使用则要手动设定之。
总结
1. DAC是很强大的一个工具，还有很多功能。
2. SQL Server要是能提供Backup Database ….WITH NO_DATA，也就不会有这么多事了。