雲開發數據庫VS傳統數據庫丨雲開發101

雲開發數據庫與傳統數據庫的不一樣

在小程序·雲開發中，最核心的即是三大組件：數據庫、雲存儲和雲函數，從今天開始，咱們將開始隔日更的專欄文章，雲開發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 數據庫的區別，以及由於這種區別所帶來的開發體驗上的不一樣，理解這些基礎內容，將會幫助你更好的應用雲開發數據庫開發你本身的產品。

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

---

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