在使用雲開發進行產品開發的時候，我們常常需要思考，我們的應用的資料結構應該如何設計，今天我們來看一些在進行應用開發時常見的一些場景的資料結構，來幫助你更好的理解雲開發，以及不同場景下雲開發的應用。
功能：判斷使用者是否註冊/留存使用者資訊以備查詢
在絕大多數場景下，使用者資訊都是我們需要儲存的資訊，或者我們需要判斷乙個使用者是否註冊時，我們會使用使用者個人資訊表來做判斷。這個時候，我們可以借助使用者個人資訊表來完成功能。
在完成這部分功能時，我們需要建立乙個名為profiles的集合，用於儲存使用者的資訊，同時，我們需要將 profiles 集合設定為僅建立者可讀寫，這樣可以確保後續我們功能可以實現。
由於我們將profiles集合設定為僅建立者可讀寫，因此，當使用者在執行資料查詢時，僅能查到自己建立的資料，因此，當我們需要實現判斷使用者是否註冊時，只需要對集合內的資料進行查詢，便可知道使用者是否建立過資料。
基於這樣的機制，我們可以讓使用者在註冊時在profiles表中建立乙個資料，這樣在後續判斷使用者是否註冊時，只需要查詢是否建立資料，便可以知道使用者是否已經註冊。
這裡我們舉個例子，當資料庫中有_openid分別為aa、bb、cc的三條記錄，如果當前使用者的 openid 為 aa，則它執行db.collection('profiles').count()時，得到的結果是 1 ，則表示這個使用者已經註冊了。如果當前使用者的 openid 為 dd，因為許可權是僅能查詢自己建立的資料，因此，在執行db.collection('profiles').count()時，得到的結果是0。
對於結果為 1 的，就視為該使用者已經註冊；對於結果為 0 的，就視為該使用者未註冊。
由於我們是基於 count 的結果來判斷使用者是否註冊，因此，就要求我們在完成使用者註冊（獲取使用者基本資訊，如頭像、暱稱）時，在profiles表中新增乙個資料，從而用於後續的判斷。
則在開發時，我們需要注意，在使用 getuserinfo 相關的元件和介面完成資料的獲取後，我們需要在profiles表中新增一條資料，具體的**可以參考下方的**
page().then(res => )}})
}})
一般來說，我們的小程式中會或多或少加入一些內容方面的內容，有的是由官方發布的，有的是由使用者發布的，根據發布者的不同，我們可以設計兩種不同的表結構
對於僅限於官方發布的，我們可以考慮建立乙個集合，名為contents，並將其許可權設定為僅管理端可寫，其他人可讀，這樣我們所新增的資料僅能在雲函式中進行修改，而不能在小程式由普通使用者修改，這樣就可以確保我們的資料的修改必須經過雲函式的確認，在雲函式中，我們可以進行許可權的判斷，比如，某幾個特定的人有許可權修改資料。
對於一些 ugc 的應用，我們需要使用者產生內容時，可以考慮建立乙個集合，名為contents，並將其許可權設定為僅建立者可寫，所有人可讀，這樣就可以實現使用者自行發布的內容，可以被其他所有使用者檢視。同時，資料的建立者可以對資料進行修改。
這一部分關鍵在於：
雲開發（cloudbase）是一款雲端一體化的產品方案 ，採用 serverless 架構，免環境搭建等運維事務 ，支援一雲多端，助力快速構建小程式、web應用、移動應用。
技術文件：
資料結構設計
mfc提供的集合類來管理文件資料，mfc提供幾種處理物件陣列的類，如集合類，這些集合類表現為下列兩種風格 1.模板為基的集合類 2.非模板為基的集合類 每個集合類又進一步按他的元素型別和他的形加以區分。集合的形指明在集合每如何組織資料，mfc提供3種通用集合類的形 array 陣列，有次序性，可以動...
單據資料結構設計
單據資料結構設計 單據形式 企業中的表單 請假單 加班單等等 大多數完成兩個功能 一 審批 二 產生業務記錄。一般情況下，會根據表單上欄位所處的位置，將其設計為單據頭 單據體那樣一對多的關係。通乙個業務可能表單的形式不盡相同，以加班單為例 有一人多天加班 有多人一天加班，有多人多天的加班。不論怎麼變...
結構設計 資料表設計 常用表結構設計
為了建立冗餘較小 結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。位址一般包括 省 市 縣 區 詳細位址 我們當然可以儲存乙個字段 使用分隔符 json 等儲存 介紹字段介紹 字段介紹 idbigint id parentid parentidlist chi...