你使用数据库项目的源代码控制？
我觉得我的商店有一个漏洞，因为我们没有一个可靠的过程来修改我们的数据库模式更改。 我们做了很多备份，所以我们或多或less地被覆盖了，但是这样做依赖于你的最后一道防线是不好的做法。
令人惊讶的是，这似乎是一个共同的线索。 我所说过的很多商店都忽略了这个问题，因为他们的数据库不会经常变化，而且基本上只是试图细致。
不过，我知道这个故事是怎么回事。 事情只是一个时间问题，排队只是错误的东西，失踪了。
有没有最佳做法呢？ 什么是一些策略已经为你工作？
必须读取在版本控制下获取您的数据库 。 检查由K.斯科特艾伦系列的post。
在版本控制方面，数据库往往是第二类甚至是第三类公民。 从我看到的情况来看，那些从未想过在一百万年内没有版本控制地编写代码的团队可以完全忽略围绕他们应用程序所依赖的关键数据库的版本控制。 我不知道如何将自己称为软件工程师，并且在数据库不像您的其他代码那样严格控制源代码级别时，保持直面的态度。 不要让这发生在你身上。 在版本控制下获取您的数据库。
数据库本身？ 没有
创build它们的脚本，包括静态数据插入，存储过程等; 当然。 它们是文本文件，它们包含在项目中，并像其他所有内容一样进行检查。
当然，在一个理想的世界里，你的数据库pipe理工具会这样做; 但是你只需要对它进行纪律处理。
我绝对喜欢Rails的ActiveRecord迁移。 它将DML抽象为ruby脚本，然后可以在源代码仓库中轻松进行版本化。
但是，通过一些工作，你可以做同样的事情。 任何DDL更改（ALTER TABLE等）都可以存储在文本文件中。 保留文件名的编号系统（或date戳记），并按顺序应用它们。
Rails在DB中还有一个“版本”表，用于跟踪上次应用的迁移。 你可以轻松地做同样的事情。
查看LiquiBase使用源代码pipe理来pipe理数据库更改。
您不应该只是login并开始input“ALTER TABLE”命令来更改生产数据库。 我所在的项目在每个客户站点上都有数据库，因此对数据库的每个更改都在两个地方完成，一个用于在新客户站点上创build新数据库的转储文件以及一个运行的更新文件在每个更新检查您的当前数据库版本号与文件中的最高数字，并更新您的数据库。 举个例子，最后几个更新：
if [ $VERSION \< '8.0.108' ] ; then psql -U cosuser $dbName << EOF8.0.108 BEGIN TRANSACTION; -- -- Remove foreign key that shouldn't have been there. -- PCR:35665 -- ALTER TABLE migratorjobitems DROP CONSTRAINT migratorjobitems_destcmaid_fkey; -- -- Increment the version UPDATE sys_info SET value = '8.0.108' WHERE key = 'DB VERSION'; END TRANSACTION; EOF8.0.108 fi if [ $VERSION \< '8.0.109' ] ; then psql -U cosuser $dbName << EOF8.0.109 BEGIN TRANSACTION; -- -- I missed a couple of cases when I changed the legacy playlist -- from reporting showplaylistidnum to playlistidnum -- ALTER TABLE featureidrequestkdcs DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey; ALTER TABLE featureidrequestkdcs ADD CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey FOREIGN KEY (cosfeatureid) REFERENCES playlist(playlistidnum) ON DELETE CASCADE; -- ALTER TABLE ticket_system_ids DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey; ALTER TABLE ticket_system_ids RENAME showplaylistidnum TO playlistidnum; ALTER TABLE ticket_system_ids ADD CONSTRAINT ticket_system_ids_playlistidnum_fkey FOREIGN KEY (playlistidnum) REFERENCES playlist(playlistidnum) ON DELETE CASCADE; -- -- Increment the version UPDATE sys_info SET value = '8.0.109' WHERE key = 'DB VERSION'; END TRANSACTION; EOF8.0.109 fi 我相信有一个更好的方法来做到这一点，但迄今为止，这对我来说是有效的。
是。 代码是代码。 我的经验法则是，我需要能够从头开始构build和部署应用程序 ，而无需查看开发或生产机器。
我所看到的最佳做法是创build一个构build脚本，以在分段服务器上报废和重build数据库。 每个迭代都有一个数据库更改的文件夹，所有的更改都是用“Drop … Create”的脚本编写的。 通过这种方式，您可以随时将版本指向想要版本化的文件夹，从而回滚到早期版本。
我相信这是用NaNt / CruiseControl完成的。
是的，我认为重要的是版本数据库。 不是数据，而是模式。
在Ruby On Rails中，这由框架用“迁移”来处理。 任何时候你改变数据库，你做一个脚本，应用更改并检查到源代码pipe理。
我的商店非常喜欢这个想法，所以我们使用shell脚本和Ant为基于Java的构build添加了function。 我们将该stream程整合到我们的部署例程中。 在其他不支持数据库版本开箱即用的框架中编写脚本来完成相同的工作是相当容易的。
Visual Studio中的新数据库项目提供了源代码pipe理和更改脚本。
他们有一个很好的工具来比较数据库，并可以生成一个脚本，将一个脚本转换成另一个脚本，或者更新一个脚本中的数据以匹配另一个脚本。
数据库模式是“粉碎”来创build许多很小的.sql文件，每个描述数据库的DDL命令一个。
+汤姆
附加信息2008-11-30
过去一年我一直在使用它作为开发者，并且非常喜欢它。 它可以很容易地将我的开发工作与生产进行比较，并生成用于发布的脚本。 我不知道是否缺lessDBA需要的“企业types”项目的function。
由于模式是“切碎”到SQL文件源代码pipe理工作正常。
一个问题是，当你使用一个数据库项目时，你需要有一个不同的思维模式。 该工具在VS中有一个“db project”，它只是sql，外加一个自动生成的本地数据库，它具有模式和一些其他的pipe理数据 – 但是没有你的应用程序数据，加上你使用的本地dev数据库应用数据开发工作。 你很less意识到自动生成的数据库，但你必须知道它在那里，所以你可以把它留下:)。 这个特殊的数据库显然是可以识别的，因为它有一个Guid的名字，
VS DB Project做了一个很好的整合其他团队成员已经在你的本地项目/关联数据库中进行的数据库更改。 但你需要额外的步骤来比较项目模式和你的本地开发数据库模式，并应用模块。 这是有道理的，但起初似乎很尴尬。
数据库项目是一个非常强大的工具。 他们不仅生成脚本，而且可以立即应用它们。 一定不要破坏你的生产分贝。 ;）
我真的很喜欢VS DB项目，我希望今后所有的数据库项目都可以使用这个工具。
+汤姆
要求开发团队使用SQL数据库源代码pipe理系统并不是防止问题发生的灵丹妙药。 数据库源代码控制本身会引入额外的开销，因为开发人员需要在一个单独的SQL脚本中保存对对象所做的更改，打开源代码pipe理系统客户端，使用客户端签入SQL脚本文件，然后将更改应用于实时数据库。
我可以build议使用名为ApexSQL Source Control的SSMS加载项。 它允许开发人员通过向导直接从SSMS轻松映射数据库对象与源代码pipe理系统。 加载项包括对TFS，Git，Subversion和其他SC系统的支持。 它还包括对源代码控制静态数据的支持。
下载并安装ApexSQL源代码控制之后，只需右键单击要进行版本控制的数据库，然后导航到SSMS中的ApexSQL Source Control子菜单。 单击链接数据库到源代码pipe理选项，select源代码pipe理系统和开发模型。 之后，您需要为您select的源代码pipe理系统提供login信息和存储库string。
您可以阅读这篇文章的更多信息： http : //solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/
我通过保存创build/更新脚本和生成samplesata的脚本来完成。
是的，我们通过将我们的SQL作为构build的一部分来实现 – 我们保留DROP.sql，CREATE.sql，USERS.sql，VALUES.sql和版本控制这些，所以我们可以恢复到任何标记的版本。
我们也有ant任务，可以在需要时重新创build数据库。
另外，SQL随后会跟随您的源代码一起被标记。
我们做源代码控制所有我们创build的对象。 为了保持开发人员的诚实（因为您可以在源代码控制中创build对象而不需要他们），我们的dbas会定期查找任何不在源代码控制中的东西，如果他们发现任何东西，他们会放弃它，而不会问是否可以。
我曾经在项目中使用的最成功的scheme是将备份和差异SQL文件结合在一起。 基本上，我们会在每次发布之后对数据库进行备份，并执行SQL转储，以便我们也可以从头开始创build空白模式。 然后，无论何时您需要对数据库进行更改，都可以在版本控制下将sql脚本添加到sql目录中。 我们总是在序列号或date前添加文件名，这样第一个变化就像01_add_created_on_column.sql，下一个脚本是02_added_customers_index。 我们的CI机器会检查这些数据，并在从备份中恢复的数据库的全新副本上依次运行它们。
我们也有一些脚本，开发人员可以使用一个命令重新初始化本地数据库到当前版本。
我有一切必要从裸机重新创build我的数据库，减去数据本身。 我确信有很多方法可以做到这一点，但是我所有的脚本等都被保存在subversion中，我们可以重build数据库结构等，把所有的东西都拿出来，运行一个安装程序。
我通常为每个修改build立一个SQL脚本，另一个修复这些修改，并将这些脚本保存在版本控制之下。
然后我们有办法根据需要创build一个新的最新数据库，并且可以在修订之间轻松移动。 每次我们做一个发布，我们把脚本集合在一起（需要一些手工工作，但实际上很难 ），所以我们也有一套可以在不同版本之间转换的脚本。
是的，在你说出来之前，Rails和其他人做的东西非常相似，但是它似乎工作的很好，所以我没有任何问题，承认我无耻地解除了这个想法:)
我使用从MySQL Workbech导出的SQL CREATE脚本，然后使用他们的“导出SQL ALTER”function，最后我创build了一系列创build脚本（当然还有编号）以及可以在它们之间应用更改的alter脚本。
3.-导出SQL ALTER脚本通常你必须手工编写ALTER TABLE语句，反映你对模型所作的修改。 但是，您可以很聪明，让Workbench为您做好工作。 只需从主菜单中select文件 – >导出 – >正向工程师SQL ALTER脚本….
这会提示你指定当前模型应该比较的SQL CREATE文件。
从步骤1中selectSQL CREATE脚本。然后，该工具将为您生成ALTER TABLE脚本，您可以对数据库执行此脚本以使其更新。
您可以使用MySQL查询浏览器或MySQL客户端来完成此操作.Voila！ 你的模型和数据库现在已经同步了！
来源： MySQL Workbench社区版：模式同步指南
所有这些脚本当然是在版本控制之下。
是的，总是。 您应该可以在需要时用一组有用的示例数据重新创build您的生产数据库结构。 如果你不这样做，随着时间的推移，一些细微的变化，让事情继续下去，那么有一天你会被咬伤，大时间。 它的保险，你可能不认为你需要，但你做这一天的价值10倍的价格！
关于数据库模型本身已经有很多讨论，但是我们也将所需的数据保存在.SQL文件中。
例如，为了有用，您的应用程序可能需要在安装中使用它：
INSERT INTO Currency (CurrencyCode, CurrencyName) VALUES ('AUD', 'Australian Dollars'); INSERT INTO Currency (CurrencyCode, CurrencyName) VALUES ('USD', 'US Dollars');
我们将在subversion下有一个名为currency.sql的文件。 作为构build过程中的手动步骤，我们将以前的currency.sql与最新的currency.sql进行比较，然后编写升级脚本。
我们版本和源代码控制着我们的数据库的一切：
- DDL（创build和更改）
- DML（参考数据，代码等）
- 数据模型更改（使用ERwin或ER / Studio）
- 数据库configuration更改（权限，安全对象，一般configuration更改）
我们使用Change Manager和一些自定义脚本来完成所有这些工作。 我们有更改pipe理器监视这些更改并通知何时完成。
我相信每个数据库都应该受到源代码控制，开发人员应该有一个简单的方法来从头创build本地数据库。 受Visual Studio for Database Professionals的启发，我创build了一个开放源代码的工具，可以对MS SQL数据库进行脚本操作，并且可以轻松地将它们部署到本地数据库引擎。 尝试http://dbsourcetools.codeplex.com/ 。 玩得开心 – 纳森
如果你的数据库是SQL Server，那么我们可能只有你正在寻找的解决scheme。 SQL源代码pipe理1.0现已发布。
http://www.red-gate.com/products/SQL_Source_Control/index.htm
这集成到SSMS中，并在您的数据库对象和您的VCS之间提供粘合。 “脚本输出”是透明的（它使用了SQL比较引擎），使用起来非常简单，开发人员不会因为采用这个过程而感到气馁。
另一种Visual Studio解决scheme是ReadyRoll ，它是作为SSDT数据库项目的子types实现的。 这需要采用迁移驱动的方法，这更适合DevOps团队的自动化需求。
我使用SchemaBank来版本控制所有的数据库模式更改：
- 从第1天起，我将数据库模式转储导入到它中
- 我开始改变我的模式devise使用Web浏览器（因为他们是基于SaaS /云）
- 当我想更新我的数据库服务器时，我从它生成更改（SQL）脚本并应用于数据库。 在Schemabank，他们要求我把我的工作做成一个版本，然后才能生成更新脚本。 我喜欢这种做法，这样我就可以随时追溯到需要的时候。
我们的团队规则是从不直接触摸数据库服务器，而不需要先存储devise工作。 但是，为了方便起见，有人可能会试图打破这个规则。 我们会再次将模式转储导入到模式库中，如果发现差异，则让它执行diff和bash操作。 尽pipe我们可以通过它来生成alter脚本，以使我们的db和schemadevise同步，但是我们只是讨厌这个。
顺便说一句，他们也让我们在版本控制树中创build分支，这样我就可以维护一个用于分级和一个用于生产。 还有一个用于编码沙箱。
一个非常整洁的基于Web的架构devise工具，具有版本控制变更pipe理。
我通过脚本化所有对象（表定义，索引，存储过程等）来控制数据库模式。 但是，对于数据本身，只需要依靠定期备份。 这确保了所有的结构变化都可以通过正确的修订历史logging来捕获，但是不会每次数据更改时都会给数据库造成负担
在我们的业务我们使用数据库更改脚本。 脚本运行时，它的名称存储在数据库中，不会再运行，除非该行被删除。 脚本是基于date，时间和代码分支命名的，因此可以控制执行。
在实际环境中运行这些脚本之前，需要进行大量的testing，因此一般来说，在开发数据库中只会发生“oopsies”。
我们正在将所有数据库移动到源代码pipe理。 我们正在使用sqlcompare来编写数据库脚本（不幸的是，这是一个专业版function），并将结果放到SVN中。
实施的成功将取决于贵组织的文化和实践。 这里的人们相信在每个应用程序中创build一个数 大多数应用程序都使用一组通用的数据库，并导致大量的数据库间依赖关系（其中一些是循环的）。 把数据库模式放到源代码控制中是非常困难的，因为我们的系统具有数据库间的依赖关系。
祝你好运，越早尝试，越早解决问题。
我在http://dbdeploy.com/上使用了ThoughtWorks的dbdeploy工具。; 它鼓励使用迁移脚本。 每个版本中，我们将更改脚本整合到单个文件中以便于理解，并允许DBA“保佑”更改。
对我来说，这一直是一个很大的烦恼 – 看起来只是对开发数据库进行快速更改，保存它（忘记保存更改脚本）太简单了，然后就卡住了。 你可以撤销你刚刚做的事情，并重做它来创build更改脚本，或者如果你想要的话也可以从头开始编写它，尽pipe花了很多时间编写脚本。
一个我曾经使用过的工具，帮助这个有一些是SQL Delta。 它将向您展示两个数据库（SQL Server / Oracle相信）之间的差异，并生成迁移A-> B所需的所有更改脚本。 它所做的另一件好事是显示生产（或testing）数据库与开发数据库之间的数据库内容之间的所有差异。 由于越来越多的应用程序存储configuration和状态，这些configuration和状态对于在数据库表中执行至关重要，因此更改脚本可以删除，添加和更改正确的行，这是一个非常痛苦的事情。 SQL Delta显示数据库中的行，就像在Diff工具中看起来一样 – 更改，添加，删除。
一个很好的工具。 这里是链接： http : //www.sqldelta.com/
RedGate非常棒，当数据库发生变化（一个很小的二进制文件）时，我们会生成新的快照，并将这个文件作为资源保存在项目中。 无论何时我们需要更新数据库，我们都使用RedGate的工具包来更新数据库，以及能够从空数据库创build新的数据库。
RedGate也使数据快照，虽然我没有亲自与他们合作，他们也一样健壮。
仅供参考这也是由Dana提出的… 存储过程/数据库模式在源代码控制
