我刚刚浏览了有关堆栈溢出的问题，我发现了一篇文章，它建议通过简单地复制 app_data 文件夹中的 mdf 文件并修改连接字符串来部署数据库。
我知道有些人在开发过程中确实在 app_code 中创建了一个 mdf 文件，但是为了上线，这真的是部署数据库的可行方式和良好实践吗？
我在开发期间通常做的是编写自己的 SQL 脚本文件来构建数据库，并在我的本地 SQL 服务器上运行它。当站点即将上线时，我在目标服务器上运行脚本并将我的站点设置为与数据库通信。老实说，我从来没有使用 app_code 文件夹来存储数据库，我通常用它来存储我的数据访问层逻辑..
我在这里做错了吗？利用 app_data 文件夹存储数据库真的是一个好习惯吗？我可以用这种方法看到的一个问题是，部署会很慢。通过 Internet 传输 mdf 文件肯定比运行我的 sql 脚本文件慢得多。期待听到您在这件事上的想法和经验。干杯。
【问题讨论】：
标签： asp.net sql-server database
我个人更喜欢您部署数据库的方法，我认为这样做有一个很大的优势：通常 Web 和 DBServer 不应该是一台机器（安全性、可维护性等），并且使用 app_code 文件夹来保存您的数据库似乎有点轻信。
【讨论】：
另一个缺点是 MDF 文件部署只能在第一次工作。一旦您活着并需要保留数据，这将是不够的。
【讨论】：
app_data 部署方案对于您没有独立数据库服务器的网站非常有用（许多免费/较便宜的主机使您能够做到这一点）。
这在理论上类似于使用 access 作为小型经典 ASP 网站的数据库的旧方法。
【讨论】：
根据我的经验，最佳实践涉及使用某种构建过程（可能是自动化的或您提到的脚本）。然后你把你的数据库分成以下几部分： 1）一次性事件——通常你会创建一次数据库；您可以插入数据一次或初始部署；架构更改 - 这些是在构建过程之外处理的。 2) 存储过程、用户函数和其他可重复事件 - 由构建过程处理。
然后，构建过程会在部署代码时部署数据库结构。
存储过程等是这样编写的，如果它们存在，它们首先被删除然后再次创建。
这些脚本然后存储在您的代码存储库中 - 而不是 mdf。现在您可以进行版本控制、历史记录、控制您的构建过程等。至于文件夹 - 我将为核心数据库结构创建一个单独的项目文件夹 - 这些与“代码”不同，应该这样对待。但它们可能应该成为您解决方案的一部分。
【讨论】：
实际上，在我看来，数据库部署对于站点工具、大规模部署等很有用。部署包含数据库的预制应用程序可以是一个简单的过程。如果此版本的后续版本得到更新，它需要做的就是知道它是否升级。如果是，则运行更新本地数据库的脚本，否则复制到新数据库中。可以简化某些有限的场景。
【讨论】：