Question

我的主要问题是数据库在哪里？

该项目将在SVN上，并使用asp.net mvc存储库模式开发。我在哪里放sql server数据库（mdf文件）？如果我把它放在app_data中，那么我的其他队友可以检查源和数据库，并在vs实例中部署数据库的情况下运行它。

此方法的问题是：

我不能将SQL Management Studio与此数据库一起使用。
大多数Web主机要求我使用其UI或SQL Management工作室部署数据库。将它放入App Data是没有意义的。
每次我从本地测试转到在Web主机上进行测试时，都必须编辑连接字符串。

如果我使用SQL Management Studio创建数据库，我的问题是：

如何使其与源代码控制保持一致（如果架构发生更改，团队成员必须重新编写数据库脚本）。
再次连接字符串。（我想在生产服务器上自动使用字符串）。

上述所有问题都有解决方案吗？也许我缺少某种形式的工具模式？

Answer 1

使用management studio或Visual Studios服务器资源管理器。 App_Data在现实世界中使用不多。

这始终是个问题。使用SqlCompare from Redgate之类的工具或Visual Studio 2010的内置数据库比较工具。
使用Web.Config transformations自动更新连接字符串。

Answer 2

我不是任何方式的专家，但这是我的合作伙伴和我为最近的ASP.NET MVC项目所做的事情：

连接字符串总是相同的，因为我们在开发机器上运行SQL Server Express，我们的暂存和生产服务器也是如此。您只需使用点而不是计算机名称（例如“。\ SQLEXPRESS”或“。\ SQL_Named_Instance”）。

或者，您也可以使用web.config转换来部署到不同的计算机。

就数据库本身而言，我们刚刚在SVN存储库中创建了一个“Database Updates”文件夹，并在需要进行更新时添加了新的SQL脚本。我一直认为最好有一个有组织的数据库更改脚本集合。

Answer 3

基本上你的两点是正确的 - 除非你在中央数据库工作，否则当别人做出改变时，每个人都必须更新他们的数据库。如果您正在使用中央数据库，您还可以进入数据库更改的问题（即：删除一列），并且不会检入相应的源代码。然后，您将全部死在水中检查源代码，或者回滚数据库。使用中央数据库也意味着开发人员无法控制何时将databsae架构更改推送给他们。

我们在每个开发人员的机器上安装了数据库（特别好，因为我们针对不同的数据库，每个开发人员都有一个支持的数据库，为我们提供了非常好的跨平台测试）。

然后是“开发”环境指向的中央“开发”数据库。它是通过每次签入的持续集成构建的，并且在成功构建/测试后，它将发布到开发中。

开发人员对其本地计算机上的数据库架构所做的更改需要检入源代码管理。它们是数据库升级脚本，可以对数据库进行从版本X到版本Y的必需更改。数据库已进行版本控制。当客户升级时，这些数据库脚本将在其数据库上运行，以便将其从当前版本升级到他们正在安装的所需版本。

这些dbpatch文件存储在以下结构中：

./dbpatches
    ./23
        ./common
            ./CONV-2345.dbpatch
        ./pgsql
            ./CONV-2323.dbpatch
        ./oracle
            ./CONV-2323.dbpatch
        ./mssql
            ./CONV-2323.dbpatch

在上面的树中，版本23有一个在任何数据库（ANSI SQL）上运行的公共dbpatch，以及需要特定于供应商的SQL的三个数据库的特定dbpatch。

我们有一个开发人员可以运行的数据库更新脚本，它运行尚未在其开发机器上运行的任何dbpatch（无论版本如何 - 因为在单个版本的开发过程中可能会有多个dbpatches提交到源代码控制）。 / p>

连接字符串在NHibernate.config中维护，但是如果存在，则使用NHibernate.User.config，但是从源代码控制中忽略NHibernate.User.config。每个开发人员都有自己的NHibernate.User.config，它指向本地数据库并设置相应的方言等。

当推送到开发时，我们有一个NAnt脚本，它在我们的配置模板中进行变量替换。在进行分段时以及在执行发布包时使用相同的脚本。 NAnt脚本使用环境的设置文件中的变量值填充模板配置文件。

Answer 4

此类问题的常见解决方案是在代码中处理数据库版本控制，而不是将数据库本身存储在版本控制中。代码通常在app_start上执行，但可以通过其他方式触发（构建/部署过程）。然后，开发人员可以运行自己的本地数据库或使用共享开发数据库。常见的术语称为数据库迁移（从一个版本迁移到另一个版本）。以下是.net工具/库的stackoverflow问题，以简化这一过程：https://stackoverflow.com/questions/8033/database-migration-library-for-net

这是我在有多个开发人员的项目上处理此问题的唯一方法。我已成功地与50多名开发人员组成的团队使用它，并且它运作良好。

Answer 5

Red Gate解决方案是使用SQL Source Control，它集成到SSMS中。它在源代码管理中维护一个sql脚本文件夹结构，您可以将其保存在保存应用程序代码的同一文件夹/存储库中。

http://www.red-gate.com/products/SQL_Source_Control/

Visual Studio中asp.net网站和数据库的正确结构

5 个答案: