開發(fā)者對(duì)復(fù)雜的數(shù)據(jù)結(jié)構(gòu)的處理能力也是體現(xiàn)開發(fā)者水平的一個(gè)度量吧。。。最近發(fā)現(xiàn)自己對(duì)一些嵌套數(shù)據(jù)結(jié)構(gòu)、層級(jí)數(shù)據(jù)結(jié)構(gòu)的處理能力不大足。。。經(jīng)常被這些把自己繞暈。。。嚴(yán)重影響開發(fā)效率。。。就稍微低總結(jié)了一下下。。。

一、mongodb設(shè)計(jì)層級(jí)關(guān)系數(shù)據(jù)(這里主要說的是mongoose)

①假設(shè)有這樣的一個(gè)場(chǎng)景。某個(gè)文章下面有評(píng)論，每個(gè)評(píng)論可以被回復(fù)，每個(gè)回復(fù)又可以被回復(fù)...

首先，我們知道，普通的一對(duì)多的關(guān)系，可以通過引用，populate操作找出相應(yīng)的引用對(duì)象，如：

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

文章與評(píng)論的關(guān)系，就是一對(duì)多。自然也是按照這種處理方式即可。

但是，評(píng)論與回復(fù)的關(guān)系，就有點(diǎn)意思了。首先，評(píng)論和回復(fù)，回復(fù)與該回復(fù)的回復(fù)雖然是不同的東西(看著就拗口)，但是這些的shema的信息都是由相同的字段構(gòu)成。也就是說，可以說是自己嵌套了多個(gè)自己。

這個(gè)時(shí)候，就要這樣處理了：

//評(píng)論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], //自評(píng)論的類型為評(píng)論類型，也就是本身類型
});

最關(guān)鍵就是最后一句，實(shí)質(zhì)上就是遞歸地引用了自身。查找的時(shí)候，也確實(shí)是需要根據(jù)上一層的subComment找到自己。套了深層的時(shí)候，查找的時(shí)候會(huì)容易繞暈，而且查找速度也會(huì)降低。建議做層級(jí)限制。

實(shí)踐小項(xiàng)目：一個(gè)簡(jiǎn)單版node+express+mongodb的圖片分享

二、實(shí)際開發(fā)場(chǎng)景中的層級(jí)關(guān)系數(shù)據(jù)

①假設(shè)有這樣的一個(gè)場(chǎng)景，有一個(gè)商品數(shù)組，每個(gè)商品有兩個(gè)維度，顏色和規(guī)格。顏色和規(guī)格的組合會(huì)產(chǎn)生的sku(可以理解為每種組合情況的一個(gè)標(biāo)識(shí))數(shù)量為顏色數(shù)量*規(guī)格數(shù)量。當(dāng)我們渲染完畢之后，顧客每切換一個(gè)規(guī)格，都要找到相應(yīng)的sku。

設(shè)想一下，假如顧客每切換一個(gè)規(guī)格，我們就根據(jù)第幾個(gè)商品，切換的規(guī)格，沒有被切換的規(guī)格去查找。那么每次都是一個(gè)三重循環(huán)。。。

這種情況下，比較好的做法就是，初始化獲得數(shù)據(jù)的時(shí)候，建立三維數(shù)據(jù),即Array[商品index][顏色][規(guī)格]。這樣每次切換，只要讀取相應(yīng)的項(xiàng)就可以找到sku了。

但是，假若商品的維度不是二維，而是多維呢，而且不一定每種組合都存在這樣的商品的呢？

構(gòu)造數(shù)據(jù)的方法，就顯得不大明智了，一是組合數(shù)過多，并不是每種組合商品都存在，而是循環(huán)太多重。

這個(gè)時(shí)候，又要利用對(duì)象去構(gòu)造數(shù)據(jù)了。

第一步，根據(jù)展示需要構(gòu)造。展示的時(shí)候，只需要知道，某個(gè)商品的某個(gè)維度是某個(gè)值即可。即：

var obj = {[
{'商品':'1',sku:'','維度1':'...','維度2':'...',...}
]}

當(dāng)點(diǎn)擊切換維度的時(shí)候，首先根據(jù)原來(lái)的維度信息，更新用戶新選的維度。遍歷該新的維度對(duì)象，與維度信息數(shù)據(jù)比較，如果一一相符則找到新的sku。然后再更新即可?！　?/p>

在這里就要明確自己的"籌碼"與"目標(biāo)"，根據(jù)哪些東西，通過哪些途徑可以到達(dá)目標(biāo)。將每一步拆分成一個(gè)小方法去做。。。

②假設(shè)有這樣的一個(gè)場(chǎng)景,首先要根據(jù)一些規(guī)則合并一些請(qǐng)求去請(qǐng)求不同的數(shù)據(jù)(即返回的數(shù)據(jù)，是多個(gè)參數(shù)結(jié)合在一起的，必須還要解析出數(shù)據(jù)原先的對(duì)應(yīng)關(guān)系)，然后獲得部分?jǐn)?shù)據(jù)。再用獲得的部分?jǐn)?shù)據(jù)中某條數(shù)據(jù)的參數(shù)去請(qǐng)求第二個(gè)接口。然后獲得不同的一些數(shù)據(jù)。

首先想到的可能是用promise處理，待兩個(gè)接口都請(qǐng)求完畢后再進(jìn)行處理。但是假如，第一個(gè)接口獲得的是大部分主要的數(shù)據(jù)，第二個(gè)是小部分的數(shù)據(jù)。這個(gè)時(shí)候，等待第二個(gè)接口似乎就有點(diǎn)"不劃算"了，特別是在用戶體驗(yàn)上，當(dāng)一個(gè)用戶打開某個(gè)頁(yè)面的時(shí)候，白屏就不好啦。　　

這個(gè)時(shí)候，我們就要善于利用對(duì)象去構(gòu)造符合我們的數(shù)據(jù)對(duì)象了。

我們可以這樣初始化一個(gè)對(duì)象:

var obj = {
 '唯一的參數(shù)1'+‘_'+'唯一的參數(shù)1的id' : {
 第一次請(qǐng)求的數(shù)據(jù) : [],
 第二次請(qǐng)求的數(shù)據(jù) : [],　
 },
 '唯一的參數(shù)2'+‘_'+'唯一的參數(shù)2的id' : {
 第一次請(qǐng)求的數(shù)據(jù) : [],
 第二次請(qǐng)求的數(shù)據(jù) : [],　
 },
 ...
}

總之，就是要找到唯一的東西，來(lái)構(gòu)造對(duì)象。然后再根據(jù)這個(gè)唯一的值把相應(yīng)的數(shù)據(jù)填上。好吧，我都說暈了?？磦€(gè)例子：

for(var i = 0;i < data.length; i++){
 for(var j = 0;j < data[i].params.length; j++){
 obj[data[i].groupId + '_' + data[i].params[j].pcId] = {};
 }
}
//請(qǐng)求數(shù)據(jù)回來(lái)后
for(var i = 0;i < data.length; i++){
 for(var j = 0;j < data[i].params.length; j++){
 obj[data[i].groupId + '_' + data[i].params[j].pcId][firstItem] = data[i].params[j].list;
 }
}
//第二次數(shù)據(jù)回來(lái)后
for(var i = 0;i < data.length; i++){
 for(var j = 0;j < data[i].params.length; j++){
 obj[data[i].groupId + '_' + data[i].params[j].pcId][moreItem] = data[i].params[j].list;
 }
}

注意，如果是用vue，因?yàn)榈诙握?qǐng)求的數(shù)據(jù)參數(shù)來(lái)自第一次，所以請(qǐng)二次數(shù)據(jù)回來(lái)之后，需要用全局api，set方法處理才會(huì)生效。

以上就是本文的全部?jī)?nèi)容，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，同時(shí)也希望多多支持腳本之家！

最新評(píng)論