从 LocalDB 解决方案到 Enterprise 实例的迁移/部署路径是什么？

Question

鉴于现存定义的SQL Server 2012的的LocalDB作为

SqlLocalDB 是 SQL Server 2012（和未来版本）的本地、低开销数据库引擎，它允许开发人员专注于开发而不是实例配置或安全。

我很好奇从 LocalDB 开发到生产实例的路径会是什么样子，尤其是考虑到用户实例（大约 SQL 2005）的问题，并且试图将其中一个实例提升到生产和开发人员会忘记哪个实例他们实际上是在努力推广。对StackOverflow的快速搜索以各种形式暴露了此类问题。在这种情况下，LocalDB 是否改进/简化了部署？

Answer 1

我很好奇从 LocalDB 开发到生产实例的路径是什么样的

...

在这种情况下，LocalDB 是否会改进/简化部署？

老实说，差别并没有那么大。虽然User Instances这不再是一个因素，但开发人员仍然很容易创建一堆 SqlLocalDb 实例，并忘记哪个实例拥有事实的“真实”版本。

LocalDb 的作用是消除设置完整​​的基于服务的 SQL Server 实例（Express 或其他）的需要，并降低安全模型的复杂性。开发人员或团队仍然需要在源代码控制和升级方面实施良好的开发实践。正如评论中所表达的，有多种方法可以将代码从本地实例提升到生产环境（希望首先通过某种质量保证/测试系统）：

• 备份/恢复
• 通过 VS/SSDT 的数据库项目
• 第三方比较工具，例如 SQL Compare
• 在源代码管理中手动放置架构/脚本/数据
• 在部署时手动生成脚本
• 导入/导出数据向导（警告：我还没有针对 SqlLocalDb 尝试过该向导）

（我故意放弃了分离/附加，因为备份/恢复更安全。使用分离，如果在分离期间或之后 .mdf 文件发生问题，您现在的数据库副本为零。如果备份出错，您仍然可以有源码。）

这些是否或多或少容易出现与今天相同类型的问题，更多地取决于团队纪律和既定程序，而不是使用 Express 还是 LocalDb 进行本地开发。恕我直言。

LocalDb 在用户实例上提供的好处是，如果您连接到 LocalDb 的单个实例，则不会出现每次使用时AttachDbFileName都会获得数据库的新副本的特定情况。最有问题的部分是您在一个实例中更改了一张表，然后从应用程序中收到错误，因为它连接到没有更改表的副本。正如您所指出的，这导致了关于 SO 的无休止的混乱和类似问题。事实上，SqlLocalDb 仍然支持AttachDbFileName，但我认为它会非常不常用（如果有的话）。

使用 LocalDb，您遇到这些问题的可能性较小，但它们仍然存在。它是一种不同的工具，具有一些优点，但仍然可能被不当使用。