您如何处理不断变化的数据库尺寸？

9

在过去大约两个月的时间里，我一直在寻找解决方案或实践来处理数据库中的发布管理。我正在寻找人们认为是处理此问题的最佳过程。

我们的数据库有3个环境：

发展历程
用户验收测试（UAT）
生产

问题是有时我们要对开发数据库中的某些内容进行更改，并需要进行部署，因此某些功能可能尚未准备好发布到UAT。

最近，我们开始使用Red Gate SQL Source控件存储所有实体（具有常规提交）。

我曾考虑过要基于变更集（例如，从变更集X到后端的所有内容现在都被推送到UAT），但这意味着人们只在将我们的代码部署到源代码管理中之前，才进行可能会造成混淆的部署（特别是因为人们健忘）。使用变更集方法的另一个问题是，如果存储过程中存在需要修复的错误，变更集编号最终将超出修订的最大变更集范围，因此，如果需要根据最大变更集重新创建数据库，我们将再次推出该错误。

关于流程有什么建议吗？

谢谢

— 犹达
source

听起来您的数据库脚本与“实际”代码不在同一源代码控制中。为什么是这样？您可以将其视为“源代码”并放在各个分支中吗？

— Mike M.

我们目前仅将脚本的开发版本存储在源代码管理中，而UAT / Production均与活动开发不同步。每当开发人员进行提交时，源代码管理中的每个脚本都会更新。单个分支的问题是我们拥有每个人都使用的1个集中式数据库（对于较大的更改，我们分支出单独的数据库）。

1

您可以为发行版创建一个分支，并且仅提交与此发行版相关的更改。所有其他更改都应在中继线上进行。您将需要两个开发数据库来实现此目的。这会是个问题吗？

听起来好像很可能很快就会过时。没有？对于我的一个项目，我们正处于数据库的大规模检修中，因此我们进行了分支分支，以便在未修改版本的数据库中仍可以进行主动开发。但是，每天我看到我们的分支版本越来越过时了，我不确定这是否可行……我以前从未真正处理过这种情况。

— 2011年

5

移居

起伏不定，位于您的仓库中，并与您的应用程序一起标记。

您甚至可以使用SQL平面文件进行DIY，这些平面文件可以修改架构并更新架构版本。您真正要做的就是：

将您的迁移保留在源代码旁边，应该对它们进行版本控制和标记
在所有环境中始终使用托管更改（迁移）
绝不允许在任何环境中进行临时修改

好了，您可以在dev中进行开发更改，但是一旦捕获到更改，您就应该始终删除数据库并通过迁移重建它。

— 节食佛
source

如果在脚本中发现错误会怎样？您是否返回sql脚本并进行更新？

— 2011年

1

不，您创建一个新的迁移（这会增加架构版本）。通过查看数据库中的架构版本，便可以知道已部署了此修补程序。

— Dietbuddha 2011年

感谢您的帮助。乍一看，这似乎是一种非常可靠的方法，并且与我们的分支策略相似。

— 2011年

2

源代码控制！

您不会在不通过svn / git / p4的情况下直接将开发二进制文件部署到生产环境中，那么为什么仅您的数据库会这样做呢？获取专用实例供开发人员测试其本地更改，但是当必须转到开发数据库时，它必须通过已签入的ddl文件。您甚至可以编写工具来自动应用这些ddl更改（我不知道有任何现有方法可以正确执行此操作）。

一旦对数据库模式更改有了限制（不再有sqlplus->问题ddl！）并且具有严格的帐户控制（没有对所有人的ddl访问权限），这应该变得更加易于管理。

— Subu Sankara Subramanian
source

1

遗憾的是，我们的数据库太大，无法在开发人员之间传递，无法运行私人会话。不仅如此，这似乎并不太倾向于基于团队的开发，因为截至目前，我在进行后端开发的同时与人们进行联系，以将两者联系在一起。我首先需要检查所有更改，然后让它们在数据库上获取最新信息，这似乎是一个很大的麻烦。

— 2011年

为什么开发数据库的大小必须与生产数据库的大小相同？它们可以具有相同的架构，您甚至可以拥有一个包含所有数据的特殊负载测试团队，但是本地dev数据库可能很小。这也避免了数据泄漏等问题。从理论上讲，产品数据根本不应该影响开发。

— Subu Sankara Subramanian

我们的所有数据都是通过数据加载过程加载的，该过程处理从客户端提供给我们的文件，然后将其转换为我们所需的数据。因此，考虑到所有数据负载都需要在开发中进行验证，因此我们无法将dev和prod数据分开。我想它并不需要相同的大小，但是它确实需要可比较的数据量，以便我们创建的报告可以生成有意义的信息。

— 2011年

不需要复制整个数据库。在Oracle中，每个用户都有自己的架构，而我们只有一个应用程序架构。为应用程序架构中的所有对象创建公共同义词。然后，每个用户都可以按照自己的模式更改对象（表，SP），如果他们以自己的方式连接，则将使用其对象名。对于不在该模式中的对象，将使用同义词。这就是我们的工作方式。

— softveda 2011年

0

跟进使用迁移的建议...可能使用支持Ruby on Rails和Entity Framework 4.3等迁移的O / RM，但这两种方法的问题是迁移是全部或全部。您（通常）无法像更改集那样选择要应用的迁移。

另一个可行的选择（如果您使用的是Microsoft堆栈，则从未提到过该平台）是使用Visual Studio数据库工具管理SQL。它内置了重构功能（重命名/删除列等）并进行了模型验证。例如，如果存储的proc引用了不再存在的列，它将通知您。

— 迈克尔·布朗
source