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