我只是在浏览有关堆栈溢出的问题，而在一篇帖子中，它建议通过简单地将app_data文件夹中的mdf文件复制并修改连接字符串来部署数据库。

我知道有人在开发过程中确实在app_code中创建了mdf文件，但是要上线，这真的是一种可行的方法，并且是部署数据库的好习惯吗？

在开发期间，我通常要做的是编写自己的SQL脚本文件来构建数据库，然后在本地SQL服务器上运行它。当站点即将上线时，我在目标服务器上运行脚本，并将站点设置为与数据库对话。老实说，我从来没有使用过app_code文件夹来存储数据库，我通常使用它来存储我的数据访问层逻辑。

我在这里做错了吗？利用app_data文件夹存储数据库真的是一个好习惯吗？我可以用这种方法看到的一个问题是，部署将很慢。跨Internet传输mdf文件肯定比运行我的sql脚本文件要慢得多。期待听到我们对此事的想法和经验。干杯。

解决方案

我个人更喜欢我们部署数据库的方法，并且我看到了一个很大的好处：通常，Web和DBServer不应是一台机器(安全性，可维护性，...)，并且利用app_code文件夹来保存数据库似乎有点荒谬。 。

另一个缺点是MDF文件部署只能在第一次使用。一旦我们活着并需要保留数据，那将是不够的。

app_data部署方案对于没有单独的数据库服务器的网站很有用(许多免费的/便宜的主机使我们可以执行此操作)。

从理论上讲，这类似于将访问权限用作小型经典ASP网站的数据库的旧方法。

以我的经验，最佳实践涉及使用某种构建过程(也许是自动化的，或者像我们提到的脚本一样)。然后，将数据库分为以下几类：
1)一次事件通常只创建一次数据库；我们可能会插入一次数据或者进行初始部署；模式更改将在构建过程之外进行处理。
2)由构建过程处理的存储过程，用户功能和其他可重复事件。

然后，构建过程将在部署代码时部署数据库构造。

编写存储过程等，以使它们(如果存在)首先被删除，然后再次创建。

这些脚本然后存储在代码存储库中，而不是mdf中。现在，我们可以进行版本控制，历史记录，控制构建过程等。至于文件夹，我将为核心数据库结构创建一个单独的项目文件夹，这些文件夹与"代码"不同，应将其视为"代码"。但是它们可能应该成为我们解决方案的一部分。

实际上，我认为DB部署对于站点工具，大量部署等很有用。部署包含db的预制应用程序可能是一个简单的过程。如果此版本的后续版本得到更新，则只需知道是否升级即可。如果是，请运行更新本地数据库的脚本，否则将其复制到新数据库中。可以简化某些有限的方案。