party-bid的三种数据结构实现

    做完了party-bid已经过了一段时间了，现在再回头来思考一下整个项目对数据的存储结构，自我觉得还是比较满意的。在老师提供的三种数据结构来在localStorage里边存储我们需要的数据中，也看到了自己实现思路的一些影子。那么我们现在就来对这三种数据结构进行一下总结吧。

    首先在做这三种数据结构练习的方式是以测试驱动的方式，就是在已经写好相应测试的情况下对需求进行实现。因为在localStorage中这种json格式的存储方式决定了会有这种多结构的存储，它们之间对比一下自然各有优劣，也许有的要好一些。在写的时候要有测试驱动开发的思想在里边，根据测试写实现代码，却也不要代码欺骗。

    1、只存acitivities一个键来保存一个活动的列表，在其中嵌套保存与对应活动相关的报名和竞价信息。如下：

activities:[{name:activity1,sign_ups:[...],bids:[{...},{...},...]},{...},……]

这种存储方式的思路就是按照逻辑结构，activities 中包含很多歌activity,每个activity又包含该活动的报名信息，以及很多个竞价的信息。竞价信息里边又有参与竞价的人的信息以及出价等这样一个逻辑。这样存储的好处就是非常符合我们思维的逻辑结构，并且打开localStorage也会显得很干净，因为都包含在一个键中。但是要修改某活动的某次竞价的竞价信息，或者添加等操作，这些修改必然要保存到localStorage中。很显然任意进行这样一个操作首先是要找到对应的活动，然后在活动中找到对应的报名或者竞价信息，然后寻找我们需要的信息。查找需要的键，并对其数据进行修改将会花费很多的时间，明显是低效的。

     2、把具体的bid信息从bids里边提取出来，减少嵌套的层数，并且给activities中的每一个activity添加一个id属性，然后在localstorage中增加一个aictivity_id的键。如下：

activities:[{id:"0",name:activity1,sign_ups:[],bids:[],bidings:[]},{...},......]
activity_ids:["0","1",......]

这与第一种方法相比，在效率上显然是进步的，因为在activities中查找竞价信息是最耗时间的。但是因为担心下层的问题，所以先砍掉了最头疼的部分，这样就明显的减轻了在增添或者修改某次竞价的竞价信息的时候查找对应的竞价的压力。

    3、在将竞价信息分离同时，将活动的报名信息也从中分离出来，分别存储在不同的localstorage键值对中，相互之间通过activity_id来关联彼此。如下：

activities:[{id:"1",name:"activity_name"},{..},...]
sign_ups:[{name:"tony",phone:"12131323",activity_id:"1"},{..},......]
bids:[{name:"竞价1",activity_id:"1",biddings:[{name:"smile",phone:"2324234",price:"23"},{...},......]},{..},......]

这样子在数据量极具增大的情况下性能的下降会相对很慢。比如查询所有有过的活动，可以从活动列表轻松得到，而不会有很多不需要的信息被同时读出来，如果需要某一个活动具体的报名信息或者竞价信息的时候，又不需要经过层层嵌套的查找得到。

    那么对于这三种数据存储结构的实现肯定是各有优劣的，我个人觉得在数据量不是很大的时候，使用第一种方案会让结构看起来很美妙，关系明确，结构清晰，而且效率也是可以接受的。那如果数据量比较大的时候，那么就必须要考虑使用效率更好的方案了，第三种会好一些。当然最好的也是最不好的就是采用一种折中的方案，折中的方案会显得很平庸，也会兼顾所有。

    这个任务中呢主要是要求在数据存储结构不同的几种情况下，不同的存取修改数据方式来实现party bid中的几个核心的功能，测试通过就ok。代码跟之前写的party bid几乎一样，就是这三种情况下需要不同的读取或者修改数据的方式。