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