js处理层级数据结构的方法小结

开发者对复杂的数据结构的处理能力也是体现开发者水平的一个度量吧。。。最近发现自己对一些嵌套数据结构、层级数据结构的处理能力不大足。。。经常被这些把自己绕晕。。。严重影响开发效率。。。就稍微低总结了一下下。。。

一、mongodb设计层级关系数据(这里主要说的是mongoose)

①假设有这样的一个场景。某个文章下面有评论，每个评论可以被回复，每个回复又可以被回复...

首先，我们知道，普通的一对多的关系，可以通过引用，populate操作找出相应的引用对象，如：

var essaySchema = new mongoose.Schema({ //文章schema user:{ type: mongoose.Schema.Types.ObjectId, //发布者的引用 ref: 'user', //引用自User Model require: true //非空 }, ...});

文章与评论的关系，就是一对多。自然也是按照这种处理方式即可。

但是，评论与回复的关系，就有点意思了。首先，评论和回复，回复与该回复的回复虽然是不同的东西(看着就拗口)，但是这些的shema的信息都是由相同的字段构成。也就是说，可以说是自己嵌套了多个自己。

这个时候，就要这样处理了：

//评论Schema定义var commentSchema = new mongoose.Schema({ content: { type: String, require: true }, created: { type: Date, "default": Date.now }, user: { type: mongoose.Schema.Types.ObjectId, //用户的引用 ref: 'user', //引用自User Model require: true //非空 }, subComment: [this], //自评论的类型为评论类型，也就是本身类型});

最关键就是最后一句，实质上就是递归地引用了自身。查找的时候，也确实是需要根据上一层的subComment找到自己。套了深层的时候，查找的时候会容易绕晕，而且查找速度也会降低。建议做层级限制。

实践小项目：一个简单版node+express+mongodb的图片分享

二、实际开发场景中的层级关系数据

①假设有这样的一个场景，有一个商品数组，每个商品有两个维度，颜色和规格。颜色和规格的组合会产生的sku(可以理解为每种组合情况的一个标识)数量为颜色数量*规格数量。当我们渲染完毕之后，顾客每切换一个规格，都要找到相应的sku。

设想一下，假如顾客每切换一个规格，我们就根据第几个商品，切换的规格，没有被切换的规格去查找。那么每次都是一个三重循环。。。

这种情况下，比较好的做法就是，初始化获得数据的时候，建立三维数据,即Array[商品index][颜色][规格]。这样每次切换，只要读取相应的项就可以找到sku了。

但是，假若商品的维度不是二维，而是多维呢，而且不一定每种组合都存在这样的商品的呢？

构造数据的方法，就显得不大明智了，一是组合数过多，并不是每种组合商品都存在，而是循环太多重。