party_bid_core是在已经做过party-bid和学过测试知识之后，再回头来思考party-bid的数据处理方式，这一次我们用到了三种数据结构。
第一种：
[{
name: "first activity",
sign_ups: [],
bids: []
}, {
name: "second activity",
sign_ups: [
{
name:"仝键",
phone:"13600000000"
},
{
name:"于硕",
phone:"15600000000"
},
{
name:"吴京川",
phone:"13800000000"
}
],
bids: [
{
name:"竞价1",
biddings : [
{
name: "仝键",
phone:"13600000000",
price: "12"
},
{
name: "于硕",
phone:"15600000000",
price: "10"
}
]
},
{
name:"竞价2",
biddings : [
{
name: "仝键",
phone:"13600000000",
price: "10"
},
{
name: "于硕",
phone:"15600000000",
price: "12"
},
{
name: "吴京川",
phone:"13800000000",
price: "10"
}
]
}
]
}];
这一种数据结构中，嵌套还是比较多的，但是每一项数据都是嵌套在activities中，我们给activities三个属性：name,sign_ups,bids.在sign_ups中存储报名者的信息（name和phone），在bids中存储竞价信息，竞价信息包括：name和biddings属性，因为每一个竞价的活动都有一个名字和与其相关的竞价者发来的竞价内容，在biddings中就存储竞价者竞价的内容，包括：竞价者的名字name，竞价者的电话号码phone，以及竞价者的竞价price。
第二种数据结构：
{
"0":{
name: "first activity",
sign_ups:[],
bids:[],
biddings:{}
},
"1": {
name: "second activity",
sign_ups: [
{
name:"仝键",
phone:"13600000000"
},
{
name:"于硕",
phone:"15600000000"
},
{
name:"吴京川",
phone:"13800000000"
}
],
bids:["竞价1","竞价2"],
biddings:{
"竞价1":[
{
phone:"13600000000",
price: "12"
},
{
phone:"15600000000",
price: "10"
}
],
"竞价2": [
{
phone:"13600000000",
price: "10"
},
{
phone:"15600000000",
price: "12"
},
{
phone:"13800000000",
price: "10"
}
]
}
}
};
第二种数据结构感觉起来就比较聪明一些，给每一个活动加了一个链接，例如：activities["1"]，就可以直接通过“1”来找到“1”对应的活动的信息，这样做的好处是不用遍历活动的所有信息来匹配我们要的某一个活动，只需要找到这个活动是不是“0”或者“1”对应的那个活动。另外不同于第一种数据结构的地方就是将biddings从bids中提了出来，不再嵌套在bids里面，虽然每开一次竞价，就要向两个数组中添加元素，但是在查询竞价信息时却是很方便的，我们可以通过遍历bids知道每一个活动下有哪一些竞价，通过遍历biddings知道每一个竞价下的竞价信息。
第三种数据结构：
activities = [
{
id:"0",
name: "first activity"
},
{
id:"1",
name: "second activity"
}
];
sign_ups = [
{
name:"仝键",
phone:"13600000000",
activity_id:"0"
},
{
name:"于硕",
phone:"15600000000",
activity_id:"0"
},
{
name:"吴京川",
phone:"13800000000",
activity_id:"0"
},
{
name:"仝",
phone:"13600000000",
activity_id:"1"
},
{
name:"于",
phone:"15600000000",
activity_id:"1"
},
{
name:"吴",
phone:"13800000000",
activity_id:"1"
}
];
bids = [
{
name: "竞价1",
activity_id:"0",
biddings:[
{
phone:"13600000000",
price: "9"
},
{
phone:"15600000000",
price: "10"
}
]
},
{
name: "竞价1",
activity_id:"1",
biddings:[
{
phone:"13600000000",
price: "12"
},
{
phone:"15600000000",
price: "10"
}
]
},
{
name: "竞价2",
activity_id:"1",
biddings:[
{
phone:"13600000000",
price: "10"
},
{
phone:"15600000000",
price: "12"
},
{
phone:"13800000000",
price: "10"
}
]
}
];
第三种数据结构的嵌套是最少的，活动单独是一组数据，报名信息是一组数据，竞价信息又是一组数据。存储活动时，给每一项活动加一个id，方便报名和竞价时查找，sign_ups数组有三个属性：name，phone，activity_id，用户报名时，我们将用户的名字和电话号码匹配给正在进行报名的活动的id，此时，id就成为了连接活动和报名信息的key，通过活动对应的id，我们就可以轻松找到此id下所有报名者的信息。同样，每一个活动可以有不止一个竞价，每一次竞价开始，都会对应一个活动。所以，我们同样可以给bids添加activity_id这个属性，加上竞价本身的名字name，和此竞价下的竞价者信息。每一次竞价下都有多个竞价者信息，包括竞价者的电话号码phone和竞价价格price。所以第三种数据结构只用到了一个嵌套。
每一种数据结构都有其优势，第一种的逻辑非常清楚，每一个数据与其他数据之间的关系很容易就观察出来，但是实际操作的时候也是最麻烦的，因为涉及很多嵌套，所以需要遍历很多次，挨层找到符合条件的数组。第二种数据结构加了一个键值，并且将biddings提出与bids分隔开来，这样的好处是，在遍历数组时，我们同样可以快速得到我们想要的结果，但是我们必须通过一个属性值来匹配相关联的内容，比如biddings中name必须匹配bids中的竞价名称。第三种数据结构嵌套是最少的，这种做法损失了逻辑上的上下级关系，所以必须通过键值关联相关的内容，但是当我们使用数据时就不用逐层查找，比如我们要找到某一个竞价者的出价，只需要在bids中找到activity_id和name匹配的竞价，遍历此竞价，通过phone就能查到数据。
个人还是比较偏好通过第二种给每一项活动键值的方式，快速查找匹配的活动。另外，通过重写三种数据结构的方式，也让我对之前自己做的数据结构有了一个新的认识，同样的功能可以有很多种实现的方式，尝试不同的方式可以加深自己对项目的理解，找到最优的数据结构，不仅更好的实现功能，还可以减轻自己很多的工作量。而通过测试来实现代码，让我加深了测试的理解，利用测试的方式小步前进，可以清楚得知道自己每一步在干什么，整体上的思维也很清晰在测试中展现出来。