asp.net网站和数据库在visual studio中的正确结构

我的主要问题是数据库去哪里？asp.net网站和数据库在visual studio中的正确结构

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

这种方法的问题是：

我不能使用SQL Management Studio中与该数据库。
大多数网络主机都要求我使用他们的UI或SQL Management Studio部署数据库。把它放在应用数据中是没有意义的。
每次我从本地测试迁移到在Web主机上进行测试时，都必须对连接字符串进行编辑。

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

我如何保持这种一致性与源控制（因扎吉不得不重新脚本分贝，如果模式改变）。
再次连接字符串。（我想在生产服务器上自动使用该字符串）。

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

来源

2010-11-29 Shawn Mclean

基本上你的两点是正确的 - 除非你正在处理中央数据库，否则当别人进行更改时，每个人都必须更新数据库。如果您正在使用中央数据库，则还可以进入数据库更改的问题（即：删除了一列），并且未检入相应的源代码。然后，你都死在水中，直到检入源代码或数据库被回滚。使用中央数据库也意味着开发人员无法控制何时将数据库模式更改推送给他们。

我们已经安装了每个开发人员的计算机上的数据库（尤其是好的，因为我们针对不同的数据块，每个开发者都有支持的数据库给我们真的很好的跨平台测试，因为我们去的一个）。

然后是“发展”环境指向的中央“发展”数据库。它通过持续集成每个签入来构建，并且在成功构建/测试时发布到开发中。需要签入到源控制

变化，开发商使他们的本地计算机上的数据库架构。它们是数据库升级脚本，用于对数据库进行从版本X到版本Y的所需更改。数据库是版本控制的。当客户升级时，这些数据库脚本将在其数据库上运行，以将其从当前版本升级到他们正在安装的所需版本。

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

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

在上述树中，版本23具有被任何数据库上运行一个共同dbpatch（是ANSI SQL），而对于一个特定dbpatch三个数据库需要供应商特定的SQL。

我们有一个数据库更新脚本，开发人员可以运行它运行任何尚未在其开发计算机上运行的dbpatch（不考虑版本 - 因为在单个版本的开发过程中可能会委托多个dbpatches进行源代码管理）。

连接字符串被保持在NHibernate.config，但是如果存在的话，NHibernate.User.config来代替，然而NHibernate.User.config从源控制忽略。每个开发人员都有自己的NHibernate.User.config，它指向他们的本地数据库并设置适当的方言等。

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

来源

2010-11-29 00:56:00

使用管理工作室或Visual Studios服务器资源管理器。 App_Data在“现实世界”中使用得并不多。

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

来源

2010-11-29 00:27:35 jfar

谢谢，我明白了上面这些Web.Config转换的文章，但它并没有告诉我该把这个文件放在哪里以及如何连接它。 – 2010-11-29 00:39:28

它在你的MVC项目的根目录下自动创建。 – jfar 2010-11-29 00:50:06

我不以任何方式的专家，但这里是我的伙伴和我做了我们最新的ASP.NET MVC项目：

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

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

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

来源

2010-11-29 00:31:23

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

这是我处理这个与多个开发项目的唯一途径。我已经与超过50位开发人员的团队成功地使用了它，并且效果很好。

来源

2010-11-29 04:58:02

红门解决方案将使用SQL源控制，它集成到SSMS中。它在保持源代码管理SQL脚本文件夹结构，它可以保持在同一文件夹/程序存储库，你让你的应用代码英寸

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

来源

2010-11-29 11:44:44

asp.net网站和数据库在visual studio中的正确结构

回答

相关问题