我们快速开发 Web 应用程序，并且正在寻找分离开发和生产数据库的方法（我们目前直接在生产环境中进行开发……这是个坏消息）。
我们使用带有 LINQ2SQL 的 ASP.NET Webforms 和用于 CRUD 的动态数据。我们如何在本地进行数据库开发，然后将更改部署到生产环境？我见过实体框架代码优先迁移，但我不知道 LINQ2SQL 有什么等价物。我们不想切换到 EF，因为我们的 CMS 是围绕 LINQ2SQL 构建的。
我们还需要在本地提供生产数据（不是最新的，但要足够新），以便在出现问题时使用真实数据进行调试。
这是我迄今为止提出的唯一想法，但远非理想：
这是一种可以接受的做事方式吗？我们可以使用更好的方法吗？
谢谢
【问题讨论】：
标签： asp.net sql-server database migration
在 SSDT 数据库项目中开发您的数据模型和过程。这样可以随时保留您希望数据库看起来相似的完美源代码控制副本。然后让工具为您生成发布脚本。
开发人员应始终在自己的本地数据库副本上进行开发。他们可以从数据库项目中签出脚本并进行更改，然后在本地发布他们可以在签入的项目中获取最新信息，合并他们的更改，再次在本地部署，测试它，然后签入他们的更改。只有在所有内容都经过测试后，您才能将更改发布到生产环境中。
您最终会将您的数据库架构非常像代码源文件一样对待。
为了将生产数据下载到您的开发服务器，我将获取生产数据库的 .bacpac 或 .dacpac 并将其导入您的本地数据库。这很有效，因为您需要架构定义以及数据，因为 prod 可能是比 dev 中的旧版本
【讨论】：
是的，我认为您基本上一针见血。这是我做过的两件事。
您在本地开发并签入您的 SQL 脚本以进行源代码控制。然后运行脚本进行部署。我所看到的效果很好的是删除/重新创建所有存储过程（看起来很可怕，但如果您相信这些脚本，它会非常有用），然后每次部署都有一次性脚本用于架构更改和数据迁移。
您会定期复制生产数据并在本地恢复。显然，这种同步只能在部署后轻松发生，因为那时本地和生产将是相同的。在我目前的工作中，我们实际上是双工写入并将副本发送到较低的环境，所以我认为这是一个选择。您可以从其他地方复制生产中的数据，然后使用该数据/编写工具将数据导入本地。
据我所知，没有简单的答案。
【讨论】：