blocks|key|770889|text|我也更喜欢脚本--易于存储在源代码管理(CVS、Git等)中，这样您就可以通过不同的方式查看更改的时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|770890|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'd prefer scripts as well -- easy to store in source control (CVS, Git, etc) so you can diff to see when changes were made.

blocks|key|2326319|text|我不相信基于diff的部署工具。这包括vsdbcmd+.schema文件，因为它们也是基于差异的。上一次我尝试使用diff工具，它很高兴地提供了通过复制/删除/重命名来更改1.5TB表.|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2326320|我的方法是始终使用升级脚本，将部署的模式从v.+N移到v.+N%2B1。这样我就能准确地知道升级是如何完成的，如果一个操作是不可能的(它需要一个持续2周的数据拷贝操作)。然后，我知道我不能这样做，我计划了我的代码更改，以便相应地发布v.Next。|style|CODE|2326321|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/dd193283.aspx|1|http://rusanu.com/2009/05/15/version-control-and-your-database/^0|J|7|0|0|O|1|U|3|9|4|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]|$A|Y|B|Z|F|G]]|9|@$A|10|B|11|1|12]]|C|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

I don't trust diff based tools for deployment. And that includes <a href="http://msdn.microsoft.com/en-us/library/dd193283.aspx" rel="nofollow">vsdbcmd</a> .schema files, since they are also diff based. Last time I tried to use a diff tool it joyfully offered to change a 1.5 TB table via copy/drop/rename...

My approach is to always use <a href="http://rusanu.com/2009/05/15/version-control-and-your-database/" rel="nofollow">upgrade scripts</a> that move the deployed schema from v. <code>N</code> to v. <code>N+1</code>. This way I know exactly how is the upgrade done, and if an operation is not possible (it would require a size-of-data copy operation lasting 2 weeks...) then I know I cannot do it and I plan my code changes for the release of v. Next accordingly.

blocks|key|1968630|text|我们使用Red生成部署脚本，并控制版本控制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1968631|“部署”和“版本控制”是SQL代码的单独问题。|1968632|需要注意的是:您的生产数据库是掌握所有数据的主数据库。因此，将定期副本安排到测试服务器，并将其用作基线。每天晚上由NUnit生成的带有基本数据的数据库(见过，笑过)通常都是无用的。如果您有10亿行，并且需要测试对它的查询，该怎么办？|1968633|版本控制:您可以使用Red工具作为基线生成模式，然后将其与此副本(或QA或其他任何内容)进行比较。release工具允许与文件夹进行比较，在我们的示例中，该文件夹在SVN控制下，并且在每个版本中都会被更新。所以我们有每个物体的完整历史|1968634|部署:我们将我们的开发脚本(也是在SVN中)应用于一个干净的"build“DB，并与另一个干净的DB进行比较。这将成为我们的部署脚本。|1968635|当然，这是相当简单的。|1968636|pro版本提供了一个API来同步和比较，这样您就可以在需要时集成到您的工具链中。不需要GUI。顺便说一句，我们使用它提供了一些特殊用户沙箱的一键同步，并附带了客户端代码。|1968637|正如Remus提到的，对于某些操作来说，它们并不是万无一失的。如果您要更改1.5TB表上的内容，我会非常喜欢地手工编写我的脚本。另一个恼人之处是related的工具习惯于将SCHEMABINDING放在相关的视图或udf上，以进行简单的检查约束更改。|1968638|我还建议阅读马丁·福勒的““进化数据库设计””，以获得一些启示。|offset|length|1968639|entityMap|0|LINK|mutability|MUTABLE|url|http://martinfowler.com/articles/evodb.html^0|0|0|0|0|0|0|0|0|D|9|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@]|9|@$R|1A|S|1B|1|1C]]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]]]

We use Red Gate to generate scripts for deployment and to control versioning.

"Deployment" and "versioning" are separate issues for SQL code.

Important to note: your production database is master with all it's data. So arrange of regular copies to a test server and use this as a baseline. A database generated by NUnit every night with basic data (seen it, had a laugh) is generally useless. What if you have a billion rows and need to test a query against it?

Versioning: You can use the Red Gate tools to generate a schema as a baseline and then compare this to this copy (or your QA or whatever). The Red Gate tools allows comparison to a folder, which is under SVN control in our case and is updated every release. So we have full history of every object

Deployment: we apply our development scripts (also in SVN) against a clean "build" DB and compare to another clean DB. This becomes our deployment script.

This is quite simplified of course.

The pro version offers an API to synch and compare so you can integrate into your tool chain if needed. No GUI needed. Incidently, we use this to provide a one click synch of some special user sandboxes complete with client code.

As Remus mentioned, they aren't foolproof for some operations. If you are changing stuff on 1.5TB tables, I'd lovingly handcode my script. Another irritation is that Red gate's tool has a habit of dropping SCHEMABINDING on a related view or udf for a simply check constraint change.

I also recommend reading Martin Fowler's <a href="http://martinfowler.com/articles/evodb.html">"Evolutionary Database Design"</a> for some inspiration

blocks|key|1968660|text|SQL比较可以生成一个SQL迁移脚本，可以在应用它之前对其进行独立检查，但也可以提供在工具中执行脚本的选项。Red建议在部署到生产数据库时使用前一种方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1968661|对于数据库版本控制，SQL源代码管理支持大多数源代码管理系统(例如，SVN、TFS等，尽管VSS支持已被废弃)。在v3中，有一个链接到工作文件夹的选项，允许您在需要时使用自己的版本控制客户端。|1968662|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

SQL Compare can either generate a SQL migration script that can be independently reviewed before applying it, but also gives the option to execute the script within the tool. Red Gate recommends using the former method when deploying to production databases. 

For database versioning, SQL Source Control support most source control systems (eg, SVN, TFS, etc, although VSS support has been deprecated). There is, in v3, an option to link to a working folder, allowing you to use your own version control client if desirable.

blocks|key|771066|text|我有一个开源(在LGPL下获得许可)工具集项目，该项目试图解决与bsn+ModuleStore+Server+(2005/2008/Azure)正确的DB模式版本控制相关的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|771067|基本上，工具集的独立部分将DB模式的SQL+Server+DB对象写入具有标准格式设置的文件中，因此只有当对象确实发生更改时文件内容才会发生更改(与VS编写的脚本非常不同，VS脚本的某些脚本日期等，将所有对象标记为已更改，即使它们实际上是相同的)。|771068|但是，如果您使用.NET，工具集就会更进一步:它允许您将SQL脚本嵌入到库或应用程序中(作为嵌入式资源)，然后让它将嵌入的脚本与数据库中的当前状态进行比较。非表相关的更改(根据马丁·福勒的定义不是“破坏性更改”)可以自动或根据请求应用(例如创建和删除对象(如视图、函数、存储过程、类型、索引)和更改脚本(需要手动编写)也可以在同一过程中应用；也可以创建新的表以及它们的设置数据。更新之后，将再次将DB模式与脚本进行比较，以确保在提交更改之前成功地进行DB升级。|771069|请注意，整个脚本和比较代码在没有SMO的情况下工作，因此在应用程序中使用bsn+ModuleStore时不会有痛苦的SMO依赖。|771070|取决于您想要访问数据库的方式，工具集提供了更多的功能--它实现了一些ORM功能，并提供了一种非常好的、基于接口的方法来调用存储过程，包括对带有原生.NET+XML类的XML和作为IEnumerable<PocoClass>的TVPs+(表值参数)的透明支持。|style|CODE|771071|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/bsn-modulestore/|1|http://martinfowler.com/articles/evodb.html^0|W|F|0|0|0|2G|8|1|0|0|2H|M|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|17|8|@$A|18|B|19|L|M]]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]|V|$5|Q|R|S|C|$T|W]]]]

I have an open-source (licensed under LGPL) toolset project which tries to address the issues related to proper DB schema versioning for (and more) SQL Server (2005/2008/Azure), the <a href="http://code.google.com/p/bsn-modulestore/" rel="nofollow">bsn ModuleStore</a>.

Basically, the standalone part of the toolset scripts the SQL Server DB objects of a DB schema into files with a standard formatting applied, so that the file contents only changes if the object really did change (very much in contrast to the scripting done by VS, which scripts some scripting date etc. as well, marking all objects as changed even if they are in fact identical).

But the toolset goes beyond that if you use .NET: it allows you to embed the SQL scripts into the library or application (as embedded resources) and then have it compare the embedded scripts with the current state in the database. Non-table-related changes (those that are not "destructive changes" as per <a href="http://martinfowler.com/articles/evodb.html" rel="nofollow">Martin Fowler's definition</a>) can be applied automatically or on request (e.g. creating and removing objects such as views, functions, stored procedures, types, indexes), and change scripts (which need to be written manually though) can be applied in the same process as well; new tables are also created, optionally along with their setup data. After the update, the DB schema is again compared against the scripts in order to ensure a successful DB upgrade before the changes are committed.

Note that the whole scripting and comparison code works without SMO, so that you don't have the painful SMO dependency when using the bsn ModuleStore in applications.

Depending on how you want to access the database, the toolset offers even more - it implements some ORM capabilities and offers a very nice and useful interface-based approach to invoke stored procedures, including transparent support for XML with native .NET XML classes and also for TVPs (Table-Valued Parameters) as <code>IEnumerable&lt;PocoClass&gt;</code>.

blocks|key|1968780|text|我们使用比较工具作为部署过程的一部分，以查看是否缺少任何需要脚本的内容，然后与开发人员讨论是否缺少脚本(通常情况下，这是一个差异，没有签入到部署位置，因为不应该将它移到prod)。但是我们总是从源代码管理中的脚本进行部署。如果您依赖于SQL或任何其他比较工具，您可能会发现自己正在移动一些不应该移动的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1968781|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We use a compare tool as part of our deployment process to see if anything needing a script is missing and then go discuss it with the developer if so (usually it is a differnce that isn't checked in to the deplyment location because it shouldn't be moved to go to prod). But we deploy from scripts that are in source control always. If you rely on SQL Compare or any other compare tool, you may find yourself moving things that should not yet be moved.

I've just inherited an SQL Server database. One of the things I will need to sort out is versioning and automated builds.

It has been suggested that I should think seriously about recommending RedGate SQL Compare, but I have to admit I am a little uneasy about it.

My reservations are...

<ul>
<li>it appears to promote use of the gui tools for db work?</li>
<li>for live apps, I prefer to work with change scripts, this avoids the last minute panic to create migration scripts at the end of each scrum cycle, and it means your update scripts can be tested by the CI. I can't see how the RedGate tool addresses this.</li>
</ul>

My gut instinct tells me to stick with the tried and tested approach of an MSBuild file and a stack of .SQL files.

I would be interested to hear if anyone has any experience on using this tool.

Is RedGate SQL Source Control for me?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我刚刚继承了一个Server数据库。我需要解决的问题之一是版本控制和自动构建。有人建议我应该认真考虑推荐RedGate SQL比较，但我不得不承认，我对此感到有点不安。我的预订是..。它似乎在推广使用gui工具进行数据库工作？对于实时应用程序，我更喜欢使用变更脚本，这避免了在每个scrum循环结束时创建迁移脚本的最后一...

问RedGate SQL源代码管理是否适合我？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问RedGate SQL源代码管理是否适合我？EN