我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
当前回答
您还可以考虑迁移解决方案。它们允许您在c#代码中指定数据库模式,并使用MSBuild上下滚动数据库版本。
我目前正在使用DbUp,它工作得很好。
其他回答
我们刚刚开始使用Team Foundation Server。如果你的数据库是中等大小的,那么visual studio有一些很好的项目集成,内置比较、数据比较、数据库重构工具、数据库测试框架,甚至数据生成工具。
但是,该模型并不适合非常大的或第三方数据库(加密对象)。我们所做的就是只存储我们定制的对象。Visual Studio / Team基础服务器在这方面工作得很好。
TFS数据库主拱。博客
MS TFS网站
首先,你必须选择适合你的版本控制系统:
Centralized Version Control system - a standard system where users check out/check in before/after they work on files, and the files are being kept in a single central server Distributed Version Control system - a system where the repository is being cloned, and each clone is actually the full backup of the repository, so if any server crashes, then any cloned repository can be used to restore it After choosing the right system for your needs, you'll need to setup the repository which is the core of every version control system All this is explained in the following article: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/
在建立了存储库之后,如果有一个中央版本控制系统,那么就有一个工作文件夹,您可以阅读本文。它展示了如何在开发环境中使用以下命令来设置源代码控制:
通过MSSCCI提供的SQL Server Management Studio, Visual Studio和SQL Server数据工具 一个第三方工具ApexSQL源代码控制
在迁移到x64平台后,我们需要对SQL数据库进行版本调整,而旧版本在迁移过程中出现了问题。我们写了一个c#应用程序,使用sqlmo将所有SQL对象映射到一个文件夹:
Root ServerName DatabaseName Schema Objects Database Triggers* .ddltrigger.sql Functions ..function.sql Security Roles Application Roles .approle.sql Database Roles .role.sql Schemas* .schema.sql Users .user.sql Storage Full Text Catalogs* .fulltext.sql Stored Procedures ..proc.sql Synonyms* .synonym.sql Tables ..table.sql Constraints ...chkconst.sql ...defconst.sql Indexes ...index.sql Keys ...fkey.sql ...pkey.sql ...ukey.sql Triggers ...trigger.sql Types User-defined Data Types ..uddt.sql XML Schema Collections* ..xmlschema.sql Views ..view.sql Indexes ...index.sql Triggers ...trigger.sql
然后,应用程序将新编写的版本与存储在SVN中的版本进行比较,如果存在差异,则更新SVN。 我们确定每晚运行一次流程就足够了,因为我们没有对SQL做那么多更改。它允许我们跟踪所有我们关心的对象的变化,并且允许我们在发生严重问题时重新构建完整的模式。
您还可以考虑迁移解决方案。它们允许您在c#代码中指定数据库模式,并使用MSBuild上下滚动数据库版本。
我目前正在使用DbUp,它工作得很好。
每个推荐RedGate工具的人都要加1分,还有额外的建议和警告。
SqlCompare also has a decently documented API: so you can, for instance, write a console app which syncs your source controlled scripts folder with a CI integration testing database on checkin, so that when someone checks in a change to the schema from their scripts folder it's automatically deployed along with the matching application code change. This helps close the gap with developers who are forgetful about propagating changes in their local db up to a shared development DB (about half of us, I think :) ).
A caveat is that with a scripted solution or otherwise, the RedGate tools are sufficiently smooth that it's easy to forget about SQL realities underlying the abstraction. If you rename all the columns in a table, SqlCompare has no way to map the old columns to the new columns and will drop all the data in the table. It will generate warnings but I've seen people click past that. There's a general point here worth making, I think, that you can only automate DB versioning and upgrade so far - the abstractions are very leaky.