我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
当前回答
这是一个非常古老的问题,然而,许多人甚至现在都在试图解决这个问题。他们所要做的就是研究Visual Studio数据库项目。没有这一点,任何数据库开发看起来都很薄弱。从代码组织到部署再到版本控制,它简化了一切。
其他回答
典型的解决方案是根据需要转储数据库并备份这些文件。
根据您的开发平台,可能会有可用的开源插件。编写自己的代码来完成这个任务通常是相当简单的。
注意:您可能希望备份数据库转储,而不是将其放入版本控制中。在版本控制中,文件可能会迅速变大,并导致整个源代码控制系统变慢(我正在回忆CVS的恐怖故事)。
我同意ESV的答案,正是出于这个原因,我开始了一个小项目,以帮助维护一个非常简单的文件中的数据库更新,然后可以在一个很长的源代码之外进行维护。它允许对开发人员以及UAT和生产进行轻松的更新。该工具适用于SQL Server和MySQL。
项目的一些特点:
允许模式更改 允许值树填充 允许单独的测试数据插入,例如。UAT 允许回滚选项(不是自动的) 维护对SQL server和MySQL的支持 有能力导入现有的数据库到版本控制与一个简单的命令(SQL server仅…仍在开发MySQL)
请查看代码以获得更多信息。
在迁移到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做那么多更改。它允许我们跟踪所有我们关心的对象的变化,并且允许我们在发生严重问题时重新构建完整的模式。
如果您有一个小型数据库,并且希望对整个数据库进行版本化,那么这个批处理脚本可能会有所帮助。它将MSSQL数据库MDF文件分离、压缩并检入Subversion。
如果您主要想要版本化您的模式,并且只有少量的引用数据,您可以使用SubSonic Migrations来处理它。这样做的好处是您可以轻松地向上或向下迁移到任何特定的版本。
我们不存储数据库模式,而是存储对数据库的更改。我们所做的是存储模式更改,以便为数据库的任何版本构建更改脚本,并将其应用于客户的数据库。我写了一个数据库实用程序,它与我们的主应用程序一起分发,它可以读取脚本,并知道需要应用哪些更新。它还具有足够的智能,可以根据需要刷新视图和存储过程。