数据存储

对于YFD和PEIR，很重要的一点是应该记住：一旦数据被收集了，我们应该如何处理这些数据。通常情况下，数据库机制和数据库模式都是在一念之间设计的，研究人员在处理过程中会渐渐后悔，其原因或者是因为他们当时的决策使现在的数据处理变得很困难，或者是因为数据库不具有扩展性。YFD在这方面的选择不是特别困难。我们在其他项目中使用MySQL，而YFD通常只涉及较简单的插入和选择语句，因此很容易搭建系统。此外，数据是人工输入的——而不是像PEIR那样连续上传，因此数据库表的大小在开发早期不是问题。主要的考虑是当增加新的数据字段时，我希望能够扩展数据库模式，因此在创建数据库模式时考虑到这一点。

另一方面，PEIR需要更细心的数据库开发。我们每几分钟就执行成千上万的基于地理的计算，因此我们采用了PostGIS，为PostgreSQL数据库增加地理对象支持。虽然MySQL提供了GIS和空间扩展，我们认为从PEIR的需求考虑，把PostGIS和PostgreSQL结合在一起是更健壮的方案。

以上的描述可能过于简化了我们的数据库设计过程，这里我需要谈一点背景。我们的团队是由10个左右的研究生组成，每个人都有自己的研究方向。正如你所料，每个人也都致力于PEIR的不同模块的工作。这种分工方式极大地影响了我们的工作方式。PEIR的数据最初是非常分散的。我们没有使用统一的数据库模式；在需要多个数据库时，就创建多个数据库，而且并没有遵循任何特定的设计模式。无论谁在PEIR的早中期加入PEIR项目，他都会对去哪里查找数据、查找什么数据以及应该和谁联系感到困惑不已。我这么说是因为我自己正是在这个时候加入PEIR。为了减轻数据分散带来的问题，我们最终冻结了所有的开发工作。一个在PEIR的各个模块都做过开发的同事，很灵活地把每个人的代码和数据库表结合起来。本次代码和模式的凝合（c onsolidation)在用户体验开发之前完成是非常必要的，而且这一点在后期中越来越明显。现在回想起来，在早期对数据存储方面付出更多的努力来进行精心设计是很值得的，而这一点也正是研究生研究的本质。

协调和代码凝合对于YFD不是问题，因为YFD只有我一个开发人员。我可以很容易改变数据库模式、用户接口和数据收集机制。我采用了Django，一个基于Python语言的Web框架，它采用了MVC(Model-View-Control，模型-视图-控制器）模式，支持敏捷高效开发。但是，我确实需要每件事都自己完成。因为我们团队的每个小组成员在统计、计算机科学、工程、GIS和环境科学上的多样性，PEIR可以完成更多的功能——最显著的是在数据处理领域，这在下一节将会介绍。因此，和一个庞大的团队一起开发，必然有其一定的优势和不足。