数据库重构-数据本地重构层

介绍

这几年，我们把敏捷方法应用到数据库设计中，总结了一些技巧，让应用在发展的时候，数据库也能进化，这是敏捷方法的一个重要属性。 我们的方法是通过持续集成和自动重构，通过数据库管理员 (DBA) 和应用程序开发人员之间的密切合作来设计数据库。 这些技术在应用程序开发的所有阶段都有效。

1 敏捷方法

近年来，出现了一种新的软件开发方法论——敏捷方法论。 这对数据库设计提出了一些新的巨大需求。 这些要求的核心是进化设计。 在敏捷项目中，假设我们无法提前确定系统的需求，所以在项目开始就进行详细设计阶段的想法是不现实的。 系统的设计必须随着软件的变化而发展。 敏捷方法，尤其是极限编程 (XP)，通过一些实践使这种进化设计成为可能。 在数据库设计上采用敏捷方法，反复迭代。

许多人会怀疑敏捷方法是否可以用于具有大型数据库组件的系统，但我们确实使用了大量敏捷和 XP 技术来解决基于大型数据库的项目中的进化和迭代问题。

本文将介绍在数据库设计中采用敏捷方法的一些实践。 当然，这并不是说我们已经完全解决了数据库演进的问题，而是想提供一些行之有效的方法。

2 积极应对变化

敏捷编程的一个显着特征是它对变化的态度。 软件过程的一般解释是尽早了解需求，停止更改需求，以这些需求作为设计的基础，停止设计的更改，然后开始构建系统。 这就是瀑布法——基于计划的生命周期。

这种方法通过做大量的前期工作来减少变化数据库重构，一旦前期工作完成，改变需求可能会导致大问题。 当需求发生变化时，这种方法会变得非常有问题，因此需求可变性对于这种过程来说是一个大问题。

另一方面，敏捷编程面对变化，拥抱变化，甚至允许在项目开发的后期进行变化。 这种态度允许尽可能多的变化，尽管会包含变化。 这些变化部分来自项目需求的不稳定性，部分来自在面临竞争压力时支持不断变化的业务环境的需要。

为了做到这一点，必须采用不同的设计态度。 设计不仅仅是一个阶段 - 一个主要在施工开始之前完成的阶段数据库重构，设计是一个持续的过程，与编码、测试甚至发布相关，这就是计划设计与演化设计的区别。 敏捷方法的一个重要贡献是以可控的方式提出进化设计，提供控制进化设计并使其可行的技术。

敏捷方法的一个重要特征是迭代开发，即在整个项目生命周期中运行多个完整的软件生命周期循环。 敏捷过程在每次迭代中都经历一个完整的生命周期，在最终产品的所需子集中完成编码、测试和集成代码。 敏捷方法的迭代时间更短，通常在一周到两个月之间，我们更喜欢更短的迭代周期。

使用敏捷方法时，最大的问题是数据库设计如何演进。 很多人认为数据库设计是一个预先计划好的工作，后期改变数据库设计方案会导致应用软件崩溃； 配置后更改数据库设计方案会导致数据迁移问题。

在过去的三年中，我们参与了一个大型项目，该项目使用了实用的进化设计方法。 该项目涉及一个 100 人的项目团队，200 多张表，并且数据库在一年半的初始开发过程中不断发展，即使它是为多个用户分发的。 一开始我们每个月迭代一次，几个月后变成双周迭代。

随着我们将这些经验教训推广到项目的越来越多的部分，从越来越多的案例中学习。 同时，我们也吸收了其他敏捷项目的一些经验。

2.1 限制

在描述实用方法之前，必须指出我们还没有解决所有的数据库演化设计问题，特别是：

(1) 我们为单个应用设计应用数据库，而不是试图整合多个数据库；

(2) 我们没有 24*7 更新数据库。

虽然很多人认为我们解决不了这个问题，但实际上这些问题是可以解决的。 当然，这还需要进一步的努力，光谈是解决不了问题的。

3 练习

我们对数据库的进化设计的方法依赖于一些重要的实践。

3.1 数据库管理员与开发人员密切合作

敏捷方法的一个重要原则是具有不同技能和背景的人可以紧密合作。 正式的会议和文件没有足够的沟通，所以他们需要一直密切合作和密切协作。 所有项目团队成员都需要紧密合作：系统分析师、项目经理、行业专家、开发人员和数据库管理员 (DBA)。

开发人员的每一项工作都可能需要DBA的帮助，开发人员和DBA需要考虑是否需要对数据库计划进行重大改动。 开发人员向 DBA 咨询如何处理变化：开发人员知道需要什么新功能，而 DBA 对应用程序中的数据有一个整体的了解。

为了达到紧密合作的效果，DBA必须让自己平易近人。 DBA 需要留出几分钟时间让开发人员提问。 必须确保 DBA 和开发人员坐在一起，以便他们可以轻松沟通。 同时，要保证应用设计会议的公开性，以便DBA随时加入。 在许多情况下，我们发现人们在 DBA 和应用程序开发人员之间制造了障碍，必须消除这些障碍才能使进化数据库设计成为可能。

3.2 每个项目组成员都有自己的数据库实例

进化设计认为人们通过尝试来学习。 在编程过程中，开发人员会在应用某个首选解决方案之前对如何实现某个功能进行一些实验。 数据库设计也是如此。 因此，重要的是每个开发者都有自己的实例来试验，不影响其他人，这样每个人都可以根据自己的需要进行试验。

很多DBA高手觉得多数据库很麻烦，在实践中不好应用，但是我们发现，操作一百个左右的数据库是非常容易的。 当然，有方便的工具让你像操作文件一样操作数据库是非常重要的。

3.3 开发者数据库通常集成到一个共享的主数据库中

虽然开发人员可以在他们自己的空间中经常进行试验，但定期将不同的努力结合起来也很重要。 应用程序开发需要一个共享的主数据库，所有工作都汇集在一起​​。 当开发人员开始工作时，他们从 master 数据库中获取一个副本到他们自己的工作区，对其进行操作和修改，然后将更改反馈回 master 数据库。 我们的政策是每个开发人员每天提交一次 confluence。

假设开发人员在上午 10 点开始开发任务，该任务的一部分是更改数据库计划。 如果改动很简单，比如增加一个字段，他可以自己决定。 在数据字典的帮助下，开发人员还必须确保他要添加的字段不在数据库中，但如果他与 DBA 讨论这种可能的更改，那么工作就容易多了。

当他准备好开始时，他会获取一份主数据库的副本，这样他就可以自由地更改数据库计划和代码。 因为他用的是自己的数据库实例，不会影响到别人。 在某个时候，比如下午 3 点，他很清楚需要对数据库进行哪些更改，尽管他还没有完全完成编码工作。 这时候，他找到DBA，告诉他自己想要的改动。 这时，DBA 可以提出开发人员没有考虑过的问题。 当然，大多数时候都很好，并且 DBA 同意更改（通过一个或多个数据库重构）。 DBA 使更改立即发生（除非它们是中断更改），因此开发人员可以继续他的工作，随时提交代码，因为 DBA 已将更改发送到主数据库。

将此原则视为类似于源代码管理中经常使用的持续集成。 实际上，这只是将数据库视为另一个源代码，因为配置管理系统控制着主数据库和源代码。 每当我们成功构建时，数据库都会与源代码一起输入配置管理系统，因此我们拥有两者的完整同步版本历史记录。

对于源代码，集成问题由源代码控制系统处理。 对于数据库来说，工作稍微多一些，所有的数据库变化都需要妥善处理，比如自动化数据库重构。 此外，DBA 需要审查任何数据库更改，以确保它们符合总体数据库计划。 为了使这项工作更加稳定，集成过程中不应有大的变化——因此 DBA 和开发人员需要紧密合作。

我们强调经常性的小型集成，因为它比不频繁的大型集成容易得多。 集成的复杂度随着集成的规模呈几何级数增长，因此在实践中进行许多小的更改更容易实现，这当然看起来有悖常理。

3.4 数据库包含规划和测试数据

当我们提到数据库时，我们不仅仅指数据库计划，还指相当大的数据。 这些数据包括应用需要的标准数据，比如全国所有省份的名称，以及一些样本客户的样本数据。

数据的作用：

(1) 易于测试

使用大量的自动化测试可以帮助稳定应用程序的开发。 此类测试通常用于敏捷方法中。 为了有效地执行这些测试，在样本测试数据的基础上工作是明智的，这样所有的测试都可以在程序正式启动之前完成。

(2) 测试数据库迁移

除了测试代码之外，示例测试数据还允许我们测试数据库迁移。 在更改数据库模式时，我们还必须确保所有模式更改也可以处理样本数据。

在大多数项目中，这些示例数据是虚构的，但在某些项目中，人们使用实际数据作为示例，在这些情况下，数据是从以前通过自动数据迁移编码的系统中提取的。 显然，并非所有数据都可以一次迁移，因为只有一小部分数据库是在早期迭代中构建的。 但是我们希望随着应用程序和数据库的发展而更改迁移代码。 这不仅可以及早解决迁移问题，还可以让行业专家轻松处理正在开发的系统。 因为他们有他们熟悉的数据，他们会指出可能导致数据库和应用程序设计问题的地方，所以我们建议在项目的早期迭代中引入真实数据。