我想知道你们如何管理2个SQL Server之间的数据库部署,特别是SQL Server 2005。 现在,有一个发展和现实的发展。由于这应该是构建脚本的一部分(标准Windows批处理,即使这些脚本的当前复杂性,我可能会在以后切换到PowerShell),企业管理器/ Management Studio Express也不计算在内。
您是否只需复制.mdf文件并附加它?在处理二进制数据时我总是要小心,因为这似乎是一个兼容性问题(即使开发和实时应该始终运行相同版本的服务器)。
或者 - 由于T-SQL中缺少“EXPLAIN CREATE TABLE” - 您是否可以将现有数据库导出到可以在目标服务器上运行的SQL-Scripts?如果是,是否有一个工具可以自动将给定的数据库转储到SQL查询中并运行命令行? (同样,企业管理器/ Management Studio Express也不计算在内。)
最后 - 鉴于实时数据库已经包含数据这一事实,部署可能不涉及创建所有表,而是检查结构的差异,而不是检查实时数据,这可能还需要数据验证/转换田野变化。
现在,我听到很多关于Red Gate产品的好东西,但对于业余爱好项目来说,价格有点陡峭。
那么,您使用什么来自动将SQL Server数据库从Test部署到Live?
答案 0 :(得分:18)
我已经开始手工编写所有DDL(创建/更改/删除)语句,将它们作为文本文件添加到我的.sln中,并使用正常的版本控制(使用subversion,但任何修订控制都应该有效)。这样,我不仅可以获得版本控制的好处,而且从dev / stage更新live也是代码和数据库的相同过程 - 标签,分支等工作都是一样的。
否则,如果您没有公司为您购买,我同意redgate价格昂贵。如果你能让一家公司为你买它,那真的是值得的!
答案 1 :(得分:13)
对于我的项目,我在REd Gate的SQL Compare和Microsoft的Database Publishing Wizard之间进行了交替,你可以免费下载 here
向导不像SQL Compare或SQL Data Compare那样灵活,但它可以解决问题。一个问题是它生成的脚本可能需要一次重新排列和/或编辑才能一次性流动。
从好的方面来说,它可以移动您的架构和数据,这对于免费工具来说并不坏。
答案 2 :(得分:7)
不要忘记微软解决问题的方法:Visual Studio 2008 Database Edition。包括用于部署数据库更改的工具,在数据库之间生成模式和/或数据更改的差异,单元测试,测试数据生成。
这是相当昂贵的,但我使用试用版一段时间,并认为它是辉煌的。它使数据库与任何其他代码一样易于使用。
答案 3 :(得分:5)
与Rob Allen一样,我使用Redgate的SQL Compare / Data Compare。我还使用Microsoft的数据库发布向导。我还有一个我在C#中编写的控制台应用程序,它使用sql脚本并在服务器上运行它。这样,您就可以从命令行或批处理脚本中使用“GO”命令运行大型脚本。
我在控制台应用程序中使用Microsoft.SqlServer.BatchParser.dll和Microsoft.SqlServer.ConnectionInfo.dll库。
答案 4 :(得分:3)
我的工作方式与Karl相同,通过保留所有SQL脚本来创建和更改我保留在源代码管理中的文本文件中的表。实际上,为了避免必须让脚本检查实时数据库来确定要运行的ALTER的问题,我通常会这样工作:
如果您从测试到生产的部分内容是数据,那么这件事情无法做到的一件事就是帮助,但如果您想管理结构而不是为一个不错但昂贵的数据库管理包付费,那么实际上并非如此非常困难。我还发现这是一种很好的方法来保持对数据库的精神跟踪。
答案 5 :(得分:2)
如果你有一家公司购买它,Quest Software的Toad内置了这种管理功能。它基本上是一个双击操作来比较两个模式并从一个模式生成一个同步脚本。
他们拥有大多数流行数据库的版本,当然包括Sql Server。
答案 6 :(得分:2)
我同意脚本编写一切是最好的方法,也是我在工作中提倡的。您应编写从数据库和对象创建到填充查找表的所有内容。
你在UI中所做的任何事情都不会被翻译(特别是对于改变......而不是第一次部署)并最终需要像Redgate提供的工具。
答案 7 :(得分:2)
使用SMO / DMO,生成架构的脚本并不困难。数据更有趣,但仍然可行。
一般来说,我采用“Script It”方法,但你可能想要考虑以下几点:
我使用过Red Gate工具,它们是优秀的工具,但是如果你负担不起,那么构建工具并以这种方式工作并不是理想的。
答案 8 :(得分:2)
我正在使用Subsonic的迁移机制,所以我只有一个带有顺序的类的dll,它有两种方法,上下。有一个持续的集成/构建脚本挂钩到nant,以便我可以自动升级我的数据库。
它不是世界上最好的东西,但它比DDL更好。
答案 9 :(得分:2)
RedGate SqlCompare是一种方式。我们定期进行数据库部署,因为我开始使用该工具,所以我从未回头。 非常直观的界面,最终节省了大量时间。
Pro版本也将负责源代码控制集成的脚本。
答案 10 :(得分:2)
我还为所有对象和数据维护脚本。为了部署,我写了这个免费的实用程序 - http://www.sqldart.com。它可以让你重新排序你的脚本文件,并在一个事务中运行整个批次。
答案 11 :(得分:1)
我同意将所有内容保存在源代码管理中并手动编写所有更改脚本。对单个版本的架构的更改将进入专门为该版本创建的脚本文件。所有存储的过程,视图等应该进入单个文件,并且就源控制而言,就像.cs或.aspx一样对待。我使用powershell脚本生成一个大的.sql文件来更新可编程性的东西。
我不喜欢自动化模式更改的应用,例如新表,新列等。在进行生产发布时,我喜欢通过命令更改脚本命令来确保每个都按预期工作。没有什么比在生产中运行大型更改脚本和获取错误更糟糕的了,因为您忘记了一些在开发中没有出现的细节。
我还了解到索引需要像代码文件一样对待并放入源代码控制中。
你绝对应该有超过2个数据库 - 开发和生活。你应该拥有一个每个人都用于日常开发任务的开发数据库。然后是一个模仿生产的临时数据库,用于进行集成测试。然后可能是最近完整的生产副本(从完整备份中恢复),如果这是可行的,那么您的上一轮安装测试将与尽可能接近实际的内容相悖。
答案 12 :(得分:1)
我将所有数据库创建为DDL,然后将该DDL包装到模式维护类中。我可能会先做各种事情来创建DDL,但从根本上说我会在代码中执行所有架构维护。这也意味着如果需要做一些不能很好地映射到SQL的非DDL内容,你可以编写过程逻辑并在DDL / DML的块之间运行它。
我的dbs然后有一个表定义当前版本,因此可以编写一组相对简单的测试:
对于单个用户应用程序,我只是运行它,对于Web应用程序,如果版本不匹配并且我们运行的是独立架构maint应用程序,我们当前会锁定用户。对于多用户,它将取决于特定的环境。
优势?我非常有信心,使用这种方法的应用程序的架构在这些应用程序的所有实例中都是一致的。它不完美,有问题,但它有效...
在团队环境中进行开发时存在一些问题,但这或多或少都是一个问题!
墨菲
答案 13 :(得分:1)
我目前正在为你做同样的事情。不仅要将SQL Server数据库从测试部署到实时数据库,还要包括本地的整个过程 - >整合 - >测试 - >生产。那么每天我能轻易做到的事情就是NAnt task with Red-Gate SQL Compare。我不是在为RedGate工作,但我不得不说这是一个不错的选择。