前言

WCDB（WeChat DataBase）是微信官方的移動端資料庫元件，致力於提供一個高效、易用、完整的移動端儲存方案。

它包含三個模組：

• WCDB-iOS/Mac
• WCDB-Android

• 資料庫損壞修復工具WCDBRepair目前正在籌備開源中。背景對於iOS開發者來說，資料庫的技術選型一直是個令人頭痛的問題。由於Apple提供的CoreData框架差強人意，使得開發者們紛紛將目光投向開源社群，尋找更好的儲存方案。 對於微信也是如此。資料庫是微信內最基礎的元件之一，訊息收發、聯絡人、朋友圈等等業務都離不開資料庫的支援。為了滿足需求，我們也對現有方案做了對比研究：目前移動端資料庫方案按其實現可分為兩類，
• 關係型資料庫，代表有CoreData、FMDB等。

• CoreData 它是蘋果內建框架，和Xcode深度結合，可以很方便進行ORM；但其上手學習成本較高，不容易掌握。穩定性也堪憂，很容易crash；多執行緒的支援也比較雞肋。
• FMDB

它基於SQLite封裝，對於有SQLite和ObjC基礎的開發者來說，簡單易懂，可以直接上手；而缺點也正是在此，FMDB只是將SQLite的C介面封裝成了ObjC介面，沒有做太多別的優化，即所謂的膠水程式碼(Glue Code)。使用過程需要用大量的程式碼拼接SQL、拼裝Object，並不方便。

• key-value資料庫，代表有Realm、LevelDB、RocksDB等。
• Realm

因其在各平臺封裝、優化的優勢，比較受移動開發者的歡迎。對於iOS開發者，key-value的實現直接易懂，可以像使用NSDictionary一樣使用Realm。並且ORM徹底，省去了拼裝Object的過程。但其對程式碼侵入性很強，Realm要求類繼承RLMObject的基類。這對於單繼承的ObjC，意味著不能再繼承其他自定義的子類。同時，key-value資料庫對較為複雜的查詢場景也比較無力。

可見，各個方案都有其獨特的優勢及劣勢，沒有最好的，只有最適合的。

而對於微信來說，我們所期望的資料庫應滿足：

• 高效；增刪改查的高效是資料庫最基本的要求。除此之外，我們還希望能夠支援多個執行緒高併發地操作資料庫，以應對微信頻繁收發訊息的場景。
• 易用；這是微信開源的原則，也是WCDB的原則。SQLite本不是一個易用的元件：為了完成一個查詢，往往我們需要寫很多拼接字串、組裝Object的膠水程式碼。這些程式碼冗長繁雜，而且容易出錯，我們希望元件能統一完成這些任務。

• 完整；資料庫操作是一個複雜的場景，我們希望資料庫元件能完整覆蓋各種場景。包括資料庫損壞、監控統計、複雜的查詢、反注入等。顯然，上述各個方案都不能完全滿足微信的需求。於是，我們造了這個“輪子” - WCDB-iOS/MacWCDB-iOS/MacWCDB-iOS/Mac（以下簡稱WCDB，均指代WCDB的iOS/Mac版本），是一個基於SQLite封裝的Objective-C++資料庫元件，提供瞭如下功能：
• 便捷的ORM和CRUD介面：通過WCDB，開發者可以便捷地定義資料庫表和索引，並且無須寫一坨膠水程式碼拼裝物件。

• WINQ（WCDB語言整合查詢）：通過WINQ，開發者無須拼接字串，即可完成SQL的條件、排序、過濾等等語句。
• 多執行緒高併發：基本的增刪查改等介面都支援多執行緒訪問，開發者無需操心執行緒安全問題。

• 執行緒間讀與讀、讀與寫操作均支援併發執行。
• 寫與寫操作序列執行，並且有基於SQLite原始碼優化的效能提升。可參考我們分享的另一篇文章《微信iOS SQLite原始碼優化實踐》

• 損壞修復：資料庫損壞一直是個難題，WCDB內建了我們自研的修復工具WCDBRepair。同樣可參考我們分享的另一篇文章《微信 SQLite 資料庫修復實踐》
• 統計分析：WCDB提供介面直接獲取SQL的執行耗時，可用於監控效能。

• 反注入：WCDB框架層防止了SQL注入，以避免惡意資訊危害使用者資料。
• ...

WCDB覆蓋了資料庫使用的絕大部分場景，且經過微信海量使用者的驗證，並將持續不斷地增加新的能力。

本文是WCDB系列文章的第一篇，主要介紹WCDB-iOS/Mac的基本用法，包含：

• ORM、CRUD與Transaction
• WINQ
• 高階用法

https://cloud.tencent.com/developer/article/1005503