雲開發資料庫與傳統資料庫的不同

在小程式·雲開發中，最核心的便是三大元件：資料庫、雲端儲存和雲函式，從今天開始，我們將開始隔日更的專欄文章，雲開發101，在第一週，我們將從最最核心的資料庫開始說起。

雲開發資料庫簡介

首先，我們先來了解一下雲開發的資料庫，雲開發資料庫是由雲開發團隊提供給雲開發使用者的資料庫服務，開發者可以在小程式、雲函式等環境中，通過簡潔易懂的函式呼叫，來獲取到對應的資料，方便開發者快速完成業務邏輯中關於資料庫的部分。

在開發過程中，你可以使用諸如 wx.cloud.database().collection('data').where({"age":10}).get() 這樣的方法獲取到資料庫中的資訊，而無需再通過服務端提供的 API 完成資料庫請求，將資料查詢的權力下放到小程式端，加快應用的迭代效率。

雲開發資料庫底層技術簡介

雲開發資料庫所使用的是 NoSQL （Not Only SQL）資料庫方案中的 MongoDB 資料庫。MongoDB 資料庫是目前業界發展的最好的 NoSQL 資料庫，可以讓開發者以 SQL 和 NoSQL 兩種方式完成資料庫結構的建設，快速完成應用的開發。

NoSQL 與 SQL

我們在傳統的 Web 應用開發過程中，大多使用的是 SQL 資料庫，如 Oracle、SQLite、MySQL、MSSQL 等，但云開發所使用的 MongoDB 則是完全不同的資料庫方案，因此，在進行資料庫結構設計時，也有所不同。錯誤的思考模型，會使得你在後續的應用開發過程中，給自己帶來無盡的麻煩。因此，也就有了我們這篇文章，向你介紹 NoSQL 世界的魅力。

Schemaless 帶來的特性

在我們使用 SQL 資料庫開發時我們需要先行設計好資料庫的結構、資料表的結構等，而 NoSQL 型資料庫，因此，讓我們在開發的時候，也會有了不同的開發模式。我們無需在進行應用開發時，先行新增表結構，我們只需要根據我們自己的使用情況，隨時增加、刪除新的欄位，完成自己的業務需求，也正是這種自由，使得雲開發有了快速開發、快速迭代的特性。

雲開發資料庫結構設計思路

由於雲開發所使用的資料庫型別與我們所熟悉的資料庫型別不同，因此，在開發的時候，我們也要相應的修改我們的資料庫結構，以適配 NoSQL 資料庫的各項特性，從而降低程式設計時的複雜度，又好又快的滿足自己的業務需求。

和 SQL 資料庫不同， MongoDB 資料庫由於其儲存結構從設計之初便是考慮分散式、多節點儲存，其 Best Practice 是「以空間換時間」，因此，在設計應用資料結構時，不要考慮應用的資料儲存空間，而是更多思考，如何以更快的速度將資料查詢出來。

但是，資料庫的設計不能完全追求時間，也要思考程式設計的複雜程度，平衡時間、空間與程式設計複雜度，以一個更好的方式完成自己的資料庫設計。

舉個例子，因為極度追求資料的空間換時間，整個資料系統的多種資料僅設計一個集合，所有的資料都掛在一個集合中，顯然是不合理的，這種儲存會導致應用後續的迭代造成麻煩。

同樣的，極度的不追求空間換時間，也是一種錯誤的選擇，如果你將所有的資料都放在各自的獨立集合中，則會造成沒有很好的利用 NoSQL 資料庫的特性，也會使得你的後續程式設計變得麻煩。

因此，在使用雲開發資料庫時，我們需要思考我們的業務發展方向，將可能會用到的場景進行割離，思考應用的資料庫結構，從而確保自己的應用在後續開發的時候不出問題。

雲開發資料庫使用常見問題

在實際的應用中，我們也看到，不少人因為不熟悉 NoSQL 的資料庫設計理念，在實際開發過程中，出現了不少的問題，這裡我們一一討論一下。

自建主鍵屬性

在 MongoDB 資料庫中，資料儲存使用的是 ObjectID，因此，其資料的 ID 並非 1 ，2 ，3 ，4 ，而是一個類似於 a718a0f318d76 hash 值，不少人在開發時，因為認為沒有自增的資料，無法完成資料排序，就自行實現了一個自增的 ID，每次新增的時候，都重新查詢一遍，獲取最新的值以後， 再重新新增資料。

但實際上，我們可以有一種更加優雅和方便的工具來完成這種需求，那就是新增一個欄位 created_at，這個欄位的值設定為當前時間的時間戳 Timestamp。當你後續需要進行資料按新增的資料進行排序時，可以使用這個欄位進行逆序排序，同時，因為這個資料使用的是當前的時間資料，你還可以將其用於資料的「創建於XX年XX月XX日」的功能，完成自己的業務需求。這個資料除了能進行直接的排序，還可以用於後續按日期匯出資料，比如篩選出某一個特定時間段的資料。

相比於一個自增的 ID，created_at 更加的簡單易用，同時，因為不需要提前獲取上一條記錄中這個欄位的值，可以有效的降低資料的查詢次數。

時間儲存問題

在我們進行業務邏輯開發時，時間資料的獲取是不可或缺的，不少人習慣於使用一個視覺化的日期資料，便會將資料庫中的日期欄位設定為 2019-09-09，以便於在使用時直接輸出到資料庫中，但實際上在開發過程中，建議大家儲存時間戳 Timestamp 來作為具體的時間。

這是因為 2019-09-09 的資料並非一個可以用於排序的欄位，在後續開發的過程中，因為你使用的是字串作為時間，如果你需要將資料進行排序，將會無法排序或出現排序錯誤的情況；此外，因為你儲存的是字串型別的時間，那麼後續如果你的業務需求發生了展示形式的變化，會導致你花費大量的時間去修改所有資料的時間，或者在資料的讀取和儲存時進行多次格式轉換，徒增麻煩。

因此，對於時間儲存有需求的，我們一貫建議大家使用時間戳來儲存，因為時間戳是一個數字型別的資料，因此可以直接進行大小的比對，同時，因為時間戳的資料是全球統一的，如果你的應用後續有全球化的需求，也可以很好的支援。

無法區分是否要拆分為獨立的資料集合儲存

在進行雲開發的資料應用開發的時候，我們發現，不少開發者的疑問是，我所使用的資料，是否有必要進行獨立拆分出一個 Collection 來進行資料儲存。

這個問題我們可以以一些簡單的問題來判斷：

1. 你所使用的資料是否有排序的需求？
2. 你所使用的資料是否有修改的需求？
3. 你所使用的資料除了在此處使用，是否還在其他地方使用？

這裡我們舉幾個例子來說明一下，比如說，我們有一個需求，是為一個內容釋出系統的文章新增評論功能，那麼我們應該如何完成這部分呢？

如果你的評論資料沒有排序、修改，也僅在此處使用，你可以考慮將評論資料放在文章資料中的一個子屬性中，這樣可以有效的完成資料查詢，你在文章進行查詢的時候，直接將評論資料查詢出來，並進行顯示，十分的方便。

如果你的評論資料有排序、修改以及其他地方使用的需求，那麼就建議你將評論資料單獨存放在一個集合中，以便在後續完成排序、更新和呼叫，如果此時你將其放在文章資料中，在後續查詢時就會有很多問題，操作起來極為不便，給自己徒增煩惱。

當然，具體情況具體分析，如果你在分析完成後，依然沒有答案，可以在公眾號後臺提出你的問題，我們將盡快給您回覆。

總結

在本次的文章中，我們分享了雲開發所使用的 NoSQL 資料庫與傳統的 SQL 資料庫的區別，以及因為這種區別所帶來的開發體驗上的不同，理解這些基礎內容，將會幫助你更好的應用雲開發資料庫開發你自己的產品。

如果你對於雲開發有任何問題，都歡迎你在文章留言出留下你的疑問，我們將一一解答。

宣發渠道

渠道：掘金、微信、知乎、KM

可適用主題：小程式雲開發相關、SQL 資料庫相關、NoSQL 資料庫相關

---

如果你想要了解更多關於雲開發CloudBase相關的技術故事/技術實戰經驗，請掃碼關注【騰訊云云開發】公眾號～

相關推薦