前言
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