我们对所有dabase创建的对象进行源代码控制。为了让开发人员保持诚实(因为你可以在没有源代码控制的情况下创建对象)，我们的dba定期寻找不在源代码控制中的任何东西，如果他们找到了什么，他们就会丢弃它，而不询问它是否ok。

是的，我认为版本化你的数据库是很重要的。当然不是数据，而是模式。

在Ruby On Rails中，这是由框架通过“迁移”来处理的。任何时候修改db，都需要编写一个脚本来应用更改并将其检入源代码控制。

我的团队非常喜欢这个想法，所以我们使用shell脚本和Ant将该功能添加到基于java的构建中。我们将该过程集成到部署例程中。在其他不支持DB版本开箱即用的框架中编写脚本来完成同样的事情是相当容易的。

作为一种规则，我们将所有的对象代码(存储过程、视图、触发器、函数等)都保存在源代码控制中，因为这些对象都是代码，而且几乎所有其他答案都同意，代码属于某种形式的版本控制系统。

As for CREATE, DROP, ALTER statements, etc. (DDL), we developed and use BuildMaster to manage the deployment of these scripts such that they can be run once and only once against a target database (whether they fail or not). The general idea is that developers will upload change scripts into the system and when it comes time for deployment, only the change scripts that haven't been run against the target environment's database will be run (this is managed very similarly to Autocracy's answer). The reason for this separation of script types lies in that once you manipulate a table's structure, add an index, etc., you effectively cannot undo that without writing a brand new script, or restoring the database - as opposed to the object code where you can simply drop a view or stored procedure then recreate it.

例如，当您将生产数据库恢复到集成环境中时，可以看到一些好处，系统会自动准确地知道哪些脚本没有运行，并将更改新恢复的数据库的表结构，使其与开发相关。

在我们的业务中，我们使用数据库更改脚本。运行脚本时，它的名称存储在数据库中，并且不会再次运行，除非删除该行。脚本是基于日期、时间和代码分支命名的，因此可以控制执行。

在脚本在实际环境中运行之前，已经完成了大量的测试，所以一般来说，“oopsies”只发生在开发数据库上。

Visual Studio中的新数据库项目提供了源代码控制和更改脚本。

他们有一个很好的工具，可以比较数据库，并可以生成一个脚本，将一个数据库的模式转换为另一个数据库，或者更新一个数据库中的数据以匹配另一个数据库。

db模式被“分解”以创建许多许多小的.sql文件，每个DDL命令一个描述db。

+tom

附加信息2008-11-30

作为一名开发人员，我在过去的一年里一直在使用它，我真的很喜欢它。它可以很容易地比较我的开发工作和生产工作，并生成用于发布的脚本。我不知道它是否缺少dba在“企业级”项目中所需要的特性。

因为模式被“分解”到sql文件中，所以源代码控制可以正常工作。

One gotcha is that you need to have a different mindset when you use a db project. The tool has a "db project" in VS, which is just the sql, plus an automatically generated local database which has the schema and some other admin data -- but none of your application data, plus your local dev db that you use for app data dev work. You rarely are aware of the automatically generated db, but you have to know its there so you can leave it alone :). This special db is clearly recognizable because it has a Guid in its name,

VS DB项目在将其他团队成员所做的DB更改集成到您的本地项目/相关DB方面做得很好。但是您需要采取额外的步骤，将项目模式与本地dev db模式进行比较，并应用mods。这是有道理的，但一开始似乎很尴尬。

DB项目是一个非常强大的工具。它们不仅生成脚本，而且可以立即应用它们。请确保不要用它破坏您的生产数据库。；）

我真的很喜欢VS DB项目，我希望在我所有的DB项目中使用这个工具。

+tom

I've heard people say you absolutely have to keep your schemas in the database. I'm not sure I agree. This really depends on the system you're working with. If your system is relatively small and the data is not terribly important. And the the speed at which you need to bring another development environment online is crucial.. then yes.. you can benefit from it. However when your schema is useless without the data and the database is extremely large, it becomes virtually impossible to "source control" your database. Sure, you can still keep your DDL code in source control but that's essentially useless. You can't get the data needed without backup/restore.

在大型数据库开发工作中，我发现备份和恢复是首选的回滚选项。当然，你可以在源代码控制中保留过程、视图、函数等，但要保留表。SQL不是必需的。此外，如果您的部署过程是无懈可击的，那么您很可能永远不需要“回滚”您的生产环境。