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