薪资20K＋案例分析之五：数据结构设计

这是一套薪资在20K+的面试题,下面以连载的形式开始对该试题进行分析，希望通过该案例的学习，能够让软件开发人员了解到软件开发的工程管理方法和系统分析方法。

首先，不要把它当作面试题，而是把它看作实际的项目，按照实际项目的组织方法进行分析与设计。

第一篇，我们分析了初次见面，用户必问的两个问题。

第二篇，我们分析了以诚相待，推荐最合适的实现方式给用户

第三篇，我们分析了系统业务流程

第四篇，我们分析了业务对象分析

有了业务对象，就可以在此基础上进行数据结构设计了。

从员工开始，很自然地想到，员工应具有的数据项包括：

其实，如果从做定制项目的角度来看，系统建设范围越小越好，对于该项目，其实只有员工编号和员工姓名两个数据项即可，但通常情况下，为了上线的系统用户体验更加好一些，可以预留一些扩展的数据项，如上设计，增加了性别、个人简介、个人照片等信息。

由于每个员工都会对应地有一个积分信息，因此，员工信息和积分信息可以合并到一起：

赛事组织者发布组织比赛的活动通知，员工报名后，成为选手，选手现场检录后，成为真正的参赛选手；由于赛事活动是每周组织一次，因此，赛事可以用时间做关键字，只有一个数据项即可，这样，可以很容易地画出下面的数据结构设计模型：

考虑到系统的性能开销，通常都会在数据结构设计时，增加一些必要的冗余字段，我们在赛事表中增加报名人数、实到人数字段，在选手表中增加姓名字段；另外，由于需求说明中要求：6

其实对于单机版本，增加“是否举行”字段纯属多余，不足6人报名，就不举行比赛即可，但是预留该字段，可以为以后如果扩展成网络报名时，就直接提供了支持。

增加冗余字段，改进一下上面的模型：

仔细观察前面分析出的类模型：

一对选手与实际参赛选手之间有强制的1：2的约束条件，场次、对阵名单、比赛成绩之间也有强制的1：1的约束条件，对阵名单与一对选手之间也是1：2的约束条件，因此，他们都可以合并处理，统一合并到场次表中，而场次表从属于赛事表，因此，得到一个如下的数据结构设计：

其中选手1与选手2配对，选手3与选手4配对，比赛结果的胜负可用用1和来表示，胜负、得分与失分都针对第一对选手。

仔细观察上述数据结构设计，如果查询选手的历史成绩，则需要进行统计计算，会影响系统性能，因此，需要改进选手表，增加历史成绩字段：

检查审核一下，没有问题。

这样，我们就设计出了数据结构，为后续的编程实现又迈出了坚定的一步。