数据库设计中的敏捷方法 |
|
| 来源：互联网 作者：未知 发布时间：2008-03-14 |
|
|
3 实践
我们有关于数据库进化设计的方法依赖于一些重要的实践。
3.1 数据库管理人员与开发人员紧密合作
敏捷方法的一个重要原则就是拥有不同技能和背景的人能够紧密合作。正式的会议和文档不能达到充分交流的效果，因此他们需要一直一起工作、亲密合作。所有的项目组成员都需要紧密合作：系统分析人员、项目经理、行业专家、开发人员以及数据库管理人员（DBA）。
开发人员的每项工作可能都需要DBA的帮助，开发人员和DBA需要考虑是否需要对数据库计划做很大的改变。开发人员向DBA咨询如何应对变化：开发人员知道需要什么新的功能，而DBA对应用中的数据有全局的观念。
为了达到亲密合作的效果，DBA必须使自己易于接近。DBA需要留出几分钟的时间，让开发人员来提问。必须确保DBA和开发人员坐在一起，这样他们就很容易沟通。同时必须确保应用设计会议是公开的，这样DBA可以随时加入进来。在很多情况下我们发现人们在DBA和应用开发人员之间建立屏障，这些屏障必须去除，这样进化数据库设计才有可能。
3.2 每个项目组成员都有自己的数据库实例
进化设计认为人们通过尝试来进行学习，在编程期间开发人员在如何实施某个特征，应用某个首选的方案之前做一些试验，数据库设计也是如此。因此，每个开发人员都有自己用来试验的实例，而不必影响其它人，这一点很重要，这样每个人都可以根据自己的需要进行试验。 www.phperz.com
许多DBA专家认为多个数据库是一种麻烦，不易于实际应用，但我们发现操作一百个左右的数据库是很容易的。当然其中很重要的是拥有便利的工具，使你像操作文件一样操作数据库。
3.3 开发人员数据库经常集成到共享主数据库
尽管开发人员可以在他们自己的空间频繁试验，但是将不同的工作定期汇合也是很重要的。应用开发需要一个共享主数据库，所有的工作都汇集于此。当开发人员开始工作时他们从主数据库获取拷贝到自己的工作空间，进行操作和修改，然后将变化反馈进入主数据库。我们的规定是每个开发人员要每天提交汇合一次。
假设开发人员上午10点开始一项开发任务，这项任务的一部分是改变数据库计划。如果这种改变很简单，如增加一个字段，他就可以自己决定。通过数据字典的帮助，开发人员还必须确保他想增加的字段数据库中没有，但是如果他与DBA讨论这种可能的变化，那么工作就要简单的多。
当他准备开始时，先从主数据库中获取一份拷贝，这样就可以自由地改变数据库计划和代码。因为他使用的是自己的数据库实例，所以不会影响别人。在某个时候，如下午3点，他很清楚需要什么样的数据库变化，甚至此时他还没有完全做完他的编码工作。这时他找到DBA，告诉他想要的变化，这时DBA可以提出开发人员没有考虑到的问题。当然大多数时候都很好，DBA同意这种变化（通过一个或多个数据库重构）。DBA使变化马上发生（除非他们是破坏性的变化），这样开发人员可以继续他的工作，在任何时候提交代码，因为DBA已经将这些变化发送给主数据库。 www.phperz.com
可以将这个原则看作类似于持续集成，持续集成常用于源码管理。实际上这就是将数据库看作是另一种源代码，因为配置管理系统象控制源代码一样控制主数据库。只要我们构建成功，数据库和源代码一起被送入配置管理系统，这样我们就有两者完整和同步的版本历史。
对于源代码来说，集成中的问题被源代码控制系统处理。对于数据库来说，要做的工作稍微多一些，所有数据库的变化都需要妥善处理，如自动化数据库重构。此外DBA需要审视任何数据库变化，保证其符合整个数据库的计划。为了使这项工作做的比较平稳，在集成的过程中不应该出现大的变化——因此需要DBA与开发人员紧密合作。
我们强调经常性的小集成，因为它比非经常性的大集成容易得多。集成的复杂度会随着集成的规模呈几何级度增加，因此做许多小的变化在实践中更易于实现，当然这看上去与直觉相抵触。
3.4 数据库包含计划和测试数据
当提到数据库的时候，我们并不仅仅指数据库计划，而且还包括相当规模的数据。这些数据包括应用所需的标准数据，如全国所有的省份名，以及一些样本客户的样本数据。
数据的作用：
(1) 易于测试 php程序员站
使用大量的自动化测试可以帮助稳定应用的发展，这样的测试在敏捷方法里是常用的方法。为了使这些测试有效进行，很理智的方法是在一个有样本测试数据的基础上工作，这样所有的测试可以在程序正式进行之前完成。
(2) 测试数据库的迁移
除了测试代码之外，样本测试数据允许我们测试数据库的迁移，当改变了数据库的计划后，我们还必须保证所有的计划变更也能够处理样本数据。
在大多数项目中这些样本数据是虚构的，然而在某些项目中人们使用实际数据作为例子，在这些情况下，数据从先前由自动化数据迁移代码的系统中提取出来。很明显不能马上迁移所有的数据，因为在早期迭代中数据库只有小部分建立起来。但是我们希望当应用和数据库发展时，改变迁移代码。这样不仅能够尽早解决迁移问题，也使行业专家易于处理这个正在开发的系统。因为有他们熟悉的数据，所以他们会指出可能给数据库和应用设计带来问题的地方，因此我们建议在项目的早期迭代中引入实际数据。 php程序员之家
3.5 所有的变化应该数据库重构
重构技术就是应用所有可控技术来改变现有的代码基础，与此类似我们定义了数据库重构也给数据库的改变提供了类似的控制。
数据库重构的不同之处在于它必须将三种不同的变化同时完成：
(1) 改变数据库计划
(2) 进行数据迁移
(3) 改变数据库存取代码
于是当描述数据库重构时，我们必须描述变化的三个方面，并确保在应用另一个重构之前完成了这三种变化。
我们必须文档化不同的数据库重构，因此我们还不能详细描述他们。然而这里有几点需要指出：像代码重构一样，数据库重构非常微小；概念链一系列微小的变化，数据库和代码很相似；变化的三个属性使保持小的变化更加重要。
许多数据库重构，如增加一个字段，可以不必更新所有存取系统的代码来完成。但是如果在使用新计划之前并不了解它，该字段将会无用，因为新计划不知道其变化之处。许多变化，没有考虑整个系统计划，我们称之为破坏性变化，如将一个已经存在的空值列设置为非空。破坏性变化需要多加留心，留心的程度依赖于包含破坏性的程度。一个小破坏性的例子是将一个已经存在的空值列设置为非空，在这种情况下你可以蒙着头做。 php程序员之家
而重构将考虑数据库中空值数据，开发人员将更新数据库映射代码，因此更新不会破坏其它人的代码；如果偶然会破坏，开发人员将在建立和使用测试时发现问题。
将一个经常使用的表分成两个是一种更复杂的破坏。在这种情况中提前让所有人知道变化到来很重要，这样他们可以有所准备。此外应该在一个更安全的时刻来实施变化。这里面很重要的一点是选择适用于你做出的变化的过程。
|
| 上一页 1 23 下一页 |
| [收藏此页] [打印本页] [返回顶部] |
|
|
|
|
|
| |
|
|
|
|
