代码之家 › 专栏 › 技术社区 › Shawn Mclean

visual studio中asp.net网站和数据库的合理结构

asp.net-mvc sql-server

Shawn Mclean · 技术社区 · 15 年前

我的主要问题是数据库去哪里了?

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

这种方法的问题是:

我不能将SQL Management Studio用于此数据库。
大多数web主机都要求我使用它们的UI或SQL Management studio部署数据库。把它放到应用程序数据中是没有意义的。
每次从本地测试转移到web主机上测试时,都必须编辑连接字符串。

如果我使用SQL Management studio创建数据库,我的问题是:

如何使其与源代码管理保持一致(如果模式发生更改,团队成员必须重新编写数据库脚本)。
再次连接字符串。(我想在生产服务器上自动使用该字符串)。

5 回复 | 直到 15 年前

Michael Shimmins 15 年前

基本上,你的两点是正确的——除非你在一个中央数据库工作,否则当其他人做出更改时,每个人都必须更新他们的数据库。如果您正在处理一个中心数据库,您还可以进入数据库更改(即:删除一列)和相应的源代码未签入的问题。然后,在源代码签入或数据库回滚之前,您都死在水里了。使用中央数据库也意味着开发人员无法控制何时将databsae模式更改推送到他们那里。

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

然后是“开发”环境指向的中央“开发”数据库。它通过持续集成每个签入来构建,并在成功构建/测试后发布给开发人员。

开发人员对本地计算机上的数据库架构所做的更改需要签入源代码管理。它们是数据库升级脚本,用于对数据库进行从版本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),以及三个需要特定于供应商的SQL的数据库的特定dbpatch。

我们有一个数据库更新脚本,开发人员可以运行它来运行任何尚未在其开发机器上运行的dbpatch(无论版本如何,因为在一个版本的开发过程中可能会有多个dbpatch提交给源代码管理)。

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

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

John Farrell 15 年前

使用management studio或Visual studio服务器资源管理器。App_数据在“现实世界”中使用的并不多。

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

Jeff Camera 15 年前

无论如何,我不是专家,但以下是我和我的合作伙伴为我们最近的ASP.NET MVC项目所做的工作:

连接字符串总是相同的,因为我们都在开发机器上运行SQL Server Express,我们的登台服务器和生产服务器也是如此。您只需使用一个点而不是计算机名(例如“.\SQLEXPRESS”或“.\SQL_Named_Instance”)。

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

至于数据库本身,我们只是在SVN存储库中创建了一个“database Updates”文件夹,并在需要进行更新时添加了新的SQL脚本。我一直认为这是一个好主意,有组织的数据库更改脚本集合无论如何。

Community Mohan Dere 9 年前

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

这是我在多个开发人员的项目中处理此问题的唯一方法。我已经成功地与超过50个开发人员的团队一起使用了这个方法,而且效果很好。

David Atkinson 15 年前

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

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