开发者对复杂的数据结构的处理能力也是体现开发者水平的一个度量吧。。。最近发现自己对一些嵌套数据结构、层级数据结构的处理能力不大足。。。经常被这些把自己绕晕。。。严重影响开发效率。。。就稍微低总结了一下下。。。 [b]一、mongodb设计层级关系数据(这里主要说的是mongoose)[/b] [b]①假设有这样的一个场景。某个文章下面有评论，每个评论可以被回复，每个回复又可以被回复...[/b] 首先，我们知道，普通的一对多的关系，可以通过引用，populate操作找出相应的引用对象，如： 文章与评论的关系，就是一对多。自然也是按照这种处理方式即可。 但是，评论与回复的关系，就有点意思了。首先，评论和回复，回复与该回复的回复虽然是不同的东西(看着就拗口)，但是这些的shema的信息都是由相同的字段构成。也就是说，可以说是自己嵌套了多个自己。 这个时候，就要这样处理了： 最关键就是最后一句，实质上就是递归地引用了自身。查找的时候，也确实是需要根据上一层的subComment找到自己。套了深层的时候，查找的时候会容易绕晕，而且查找速度也会降低。建议做层级限制。 [b]实践小项目：[url=https://github.com/LuckyWinty/PhotoSharingPlatform]一个简单版node+express+mongodb的图片分享[/url][/b] [b]二、实际开发场景中的层级关系数据[/b] [b]①假设有这样的一个场景，有一个商品数组，每个商品有两个维度，颜色和规格。颜色和规格的组合会产生的sku(可以理解为每种组合情况的一个标识)数量为颜色数量*规格数量。当我们渲染完毕之后，顾客每切换一个规格，都要找到相应的sku。[/b] 设想一下，假如顾客每切换一个规格，我们就根据第几个商品，切换的规格，没有被切换的规格去查找。那么每次都是一个三重循环。。。 这种情况下，比较好的做法就是，初始化获得数据的时候，建立三维数据,即Array[商品index][颜色][规格]。这样每次切换，只要读取相应的项就可以找到sku了。 [b]但是，假若商品的维度不是二维，而是多维呢，而且不一定每种组合都存在这样的商品的呢？[/b] 构造数据的方法，就显得不大明智了，一是组合数过多，并不是每种组合商品都存在，而是循环太多重。 这个时候，又要利用对象去构造数据了。 第一步，根据展示需要构造。展示的时候，只需要知道，某个商品的某个维度是某个值即可。即： 当点击切换维度的时候，首先根据原来的维度信息，更新用户新选的维度。遍历该新的维度对象，与维度信息数据比较，如果一一相符则找到新的sku。然后再更新即可。　　 在这里就要明确自己的"筹码"与"目标"，根据哪些东西，通过哪些途径可以到达目标。将每一步拆分成一个小方法去做。。。 [b]②假设有这样的一个场景,首先要根据一些规则合并一些请求去请求不同的数据(即返回的数据，是多个参数结合在一起的，必须还要解析出数据原先的对应关系)，然后获得部分数据。再用获得的部分数据中某条数据的参数去请求第二个接口。然后获得不同的一些数据。[/b] 首先想到的可能是用promise处理，待两个接口都请求完毕后再进行处理。但是假如，第一个接口获得的是大部分主要的数据，第二个是小部分的数据。这个时候，等待第二个接口似乎就有点"不划算"了，特别是在用户体验上，当一个用户打开某个页面的时候，白屏就不好啦。　　 这个时候，我们就要善于利用对象去构造符合我们的数据对象了。 我们可以这样初始化一个对象: 总之，就是要找到唯一的东西，来构造对象。然后再根据这个唯一的值把相应的数据填上。好吧，我都说晕了。看个例子： 注意，如果是用vue，因为第二次请求的数据参数来自第一次，所以请二次数据回来之后，需要用全局api，set方法处理才会生效。 以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，同时也希望多多支持编程素材网！