这是关于如何在开发团队中处理数据库架构更改的更一般的问题。
我们是一个开发团队，开发过程中使用的数据库在每个人的机器上本地运行，因为我们希望避免一直需要访问 Web。因此，在某处运行单个中央数据库实例并不是一个真正的选择。
每当我们中的一个人决定是时候扩展/更改 db 模式时，我们都会通过邮件发送数据库文件 (MYI/MYD) 或 SQL 文件以执行，或者在电话上向其他人指示他们需要做什么来获取更改的代码在他们的本地数据库上运行。这肯定不是完美的方法。当新版本准备好后，当我们需要在暂存或生产中调整数据库模式时，也会出现同样的问题。
我想知道......你们如何处理这种事情？对于源代码，我们使用 SVN。
非常感谢您的意见！
谢谢，迈克尔
我们过去使用的一种方法是为数据库编写整个 DDL 脚本，以及所需的任何测试/设置数据。将其存储在 SVN 中，然后当有更改时，任何开发人员都可以拉下更改，删除数据库，然后从脚本文件中重建它。
至少您应该将数据库中所有对象（表、存储过程等）的脚本置于源代码控制之下。
我不认为邮件模式更改是专业开发团队的真正选择。
在我以前的一个团队中，我们有一个系统，这是我遇到的最好的处理这种情况的系统。
应用程序的夜间构建包括数据库 (SQL Server) 的构建。该数据库已构建到测试数据库服务器。然后每个开发人员都有一个 DTS 包（这是不久前的事，我确信他们升级到了 SSIS 包）以将夜间数据库构建拉到他们的本地数据库环境中。
这将主副本保存在一个位置，并使开发人员有责任保持本地开发数据库的最新状态。
在我的工作中，我们处理生成非常耗时的大型数据库，因此对我们来说，从头开始使用新数据库并不理想。像 Harper 一样，我们在 SVN 中有我们的 DDL。此外，我们将版本号存储在数据库表中。每次更改数据库的签入都必须附有以下脚本：
此外，我们对脚本和数据库版本进行编号，以便我们编写的脚本知道如何沿着分支进一步升级或从旧分支升级到新分支，而无需开发人员的任何输入（除了数据库名称和目录升级脚本）。
因此，如果我有一个客户的 4GB 数据库的副本，它来自一年前的版本，并且我想测试他们的数据如何与我们昨天删除的版本一起工作，我可以运行我们的脚本并让它处理升级而不是而不是必须从头开始并重做自数据库创建以来执行的每个 INSERT、UPDATE 和 DELETE。
我们有数据库模式的非 SQL 描述。当应用程序启动时，它将所需的数据库模式与实际的数据库模式进行比较，并执行它需要执行的任何 ADD TABLE、ADD COLUMN、ADD INDEX 等语句以使数据库看起来正确。
这并不能处理所有情况。如果您更改了架构解析器无法处理的内容，有时您必须删除数据库并重新创建，但大多数时候我们不需要担心它。
我当然会将数据库模式保留在源代码控制中。
在我目前的工作中，每次模式发生变化时，我们都会为变化编写 SQL（alter table xyz add column ...）并将其放入 SVN 中。然后开发人员可以通过运行此脚本来更新测试数据库。这很笨拙，但它有效。
在以前的工作中，我编写了一些代码，在应用程序启动时会自动将实际的数据库模式与预期的进行比较，如果它不是最新的，则执行更新。这主要是出于部署原因：当我们发布软件的新副本时，它会自动更新用户的数据库。但它对开发人员也很方便。
我认为应该有一些通用的 SQL 工具来做到这一点。也许有，但我从未见过。