GRDB.swift 为什么值得采用设计原则、并发模型与数据库观察实战解析【免费下载链接】GRDB.swiftA toolkit for SQLite databases, with a focus on application development项目地址: https://gitcode.com/GitHub_Trending/gr/GRDB.swift本篇技术指南以 GRDB.swift 官方文档《Why Adopt GRDB?》为骨架逐一拆解其四大核心设计原则——记录类型、原生 SQL、单一事实来源、面向应用开发——并结合仓库源码深入讲解任意 Swift 类型转记录、跨线程安全、ValueObservation 数据库观察、DatabaseQueue/DatabasePool 并发模型等关键能力。读完本文你将理解 GRDB 与 FMDB、SQLite.swift、Core Data、Realm 等方案的差异根源并掌握用「值类型记录 变更通知」构建 SwiftUI/UIKit 数据层的完整实战思路。一、核心设计原则GRDB 的立身之本GRDB 文档在开篇即声明其设计哲学这些原则决定了后续所有 API 的形态。理解它们是评估「为什么采用 GRDB」的第一步。1.1 通过记录类型访问数据库通常更容易player.name比playerRow[name]更自然——数据库行Row本身不是一个适合日常处理的类型而普通模型类型才是。因此 GRDB 认为优秀的数据库工具应该允许开发者以记录record为单位编程。但 GRDB 明确站队第二代 ORM第一代记录类型的特性如自动更新auto-updating、唯一化uniquing、关系懒加载lazy loading of relations在 Swift、Rust 等强调不可变性、内存安全和函数式编程的语言时代被认为是有害的——它们是多线程头痛问题的根源。GRDB 与 Rust 的 Diesel 一样主张记录类型应该表现为普通、简单的值。1.2 原生 SQL 有时才是正确的工具复杂的数据库查询往往需要在 SQL shell 中反复原型化和调试。一旦查询定型把它逐字翻译成查询构建器的调用既漫长又痛苦且结果代码往往不如原始 SQL 可读。因此 GRDB 的原则是当查询构建器不再有用时想写原生 SQL 的人永远应该被欢迎。这一原则在仓库中随处可见GRDB 提供db.execute(sql:arguments:)、Row.fetchCursor(db, sql:)等整套 SQL API见 GRDB/Core/DatabaseStatements.swift甚至还有SQLInterpolation这套兼顾安全与可读性的 SQL 构建方案详见 Documentation/SQLInterpolation.md。1.3 数据库文件是唯一的事实来源Core Data 的每个托管对象上下文都持有数据库的一份版本Realm 的每个应用线程也有自己的数据库版本且伴随复杂的同步点。这些设计在某些场景如充满检查器面板和嵌套撤销栈的 macOS 应用有用但仅此而已。GRDB 则假设多数应用需要把数据库当作可靠、无歧义的存储。这个原则直接推导出后文的两个关键能力——记录不自动更新值类型语义与基于数据库变更的观察通知单一事实来源。1.4 应用开发者有特定的需求GRDB 把全部筹码押在 SQLite 上专注前端 GUI 应用。这意味着处理服务器、MySQL、PostgreSQL 不在范围内——GRDB 不是 Vapor Fluent 或 Perfect StORM 的替代品专注 SQLite 和应用使 GRDB 得以构建通常只有公司赞助库才有的功能迁移migrations、记录比较、数据库观察、多线程安全、表视图动画支持、响应式流Combine/RxSwift直面 Core Data 或 Realm 的多线程难题就必须正视数据库并发与记录的真相这是 GRDB 的赌注。二、解决实际问题GRDB 如何回应其他持久化库的痛点原则存在的意义是解决其他持久化库的困难与局限。以下六个小节逐一对应原文档的六大实战议题。2.1 让任意 Swift struct 或 class 成为数据库记录多数提供记录类型的库要求你继承根类Core Data 的NSManagedObject、Realm 的Realm.Object、FCModel。问题在于它们是类——你无法从纯 Swift 结构体定义记录也就无法利用值类型的一切优点不可变性、多线程安全。GRDB 用三个协议解决这一问题且全部通过扩展而非继承获得第一步FetchableRecord——从 SQL 请求加载记录struct Place { var id: Int64? let title: String let coordinate: CLLocationCoordinate2D } extension Place: FetchableRecord { ... } let places try Place.fetchAll(db, sql: SELECT * FROM place) // [Place]在源码层面FetchableRecord协议只要求实现一个初始化器init(row: Row) throws并基于它派生出fetchCursor、fetchAll、fetchSet、fetchOne等一整套获取方法见 GRDB/Record/FetchableRecord.swift。fetchAll的实现本质上是try Array(fetchCursor(statement, arguments: arguments, adapter: adapter))——把懒游标物化为数组FetchableRecord.swift。第二步TableRecord——自动生成 SQL 请求extension Place: TableRecord { ... } let place try Place.fetchOne(db, key: 1) // Place?TableRecord通过databaseTableName默认从类型名推导Player→playerPostalAddress→postalAddress见 GRDB/Record/TableRecord.swift将类型绑定到一张表并提供filter、order、select、limit、fetchCount、deleteAll等构建查询接口的静态方法。表名推导规则在源码中有精确实现全大写缩写TOEFL→toefl与小驼峰类型名HTTPRequest→httpRequest均有专门处理。第三步PersistableRecord——记录知道如何插入、更新、删除自己extension Place: PersistableRecord { ... } try place.delete(db)PersistableRecord继承自MutablePersistableRecord提供insert、save、upsert、delete等持久化方法以及willInsert(_:)、didInsert(_:)等回调钩子——后者可用于在插入后捕获自增主键见 GRDB/Record/PersistableRecord.swift。Codable 记录的免费加成这三个协议都可以从标准库的Decodable/Encodable自动派生。Codable记录甚至获得 JSON 列支持等额外便利。以Decodable为例GRDB 提供了databaseColumnDecodingStrategy蛇形命名转驼峰等、databaseDateDecodingStrategy、databaseDataDecodingStrategy、databaseJSONDecoder(for:)等可定制的解码策略见 FetchableRecord.swift默认的 JSON 解码器配置为dataDecodingStrategy .base64、dateDecodingStrategy .millisecondsSince1970。设计要点GRDB 记录是普通值不自动更新、不唯一化。下文将看到这些缺失的功能可以用数据库变更通知来替代且带来更多优势。2.2 让数据库记录自由跨越线程一旦记录是不可变的值它们就能安全地在不同线程间使用。你不再需要像 Core Data 或 Realm 那样在线程间传递对象 id 或引用if let player try Player.fetchOne(db, key: 1) { DispatchQueue.main.async { nameField.text player.name } }fetchOne返回的是一个完整的Player值它不持有任何数据库连接因此可以自由逃逸到主线程使用。这正是值类型记录相对对象图记录的核心优势没有线程亲和性。需要留意的是RecordCursor在源码中被显式标记为available(*, unavailable) extension RecordCursor: Sendable见 FetchableRecord.swift因为游标必须在其创建所在的串行数据库访问队列中被消费——这是数组可跨线程、游标不可跨线程这一规则在类型系统层面的强制。2.3 用数据库变更通知替代自动更新记录GRDB 记录是普通值与应用中其他值一样与数据库无绑定。你有时手工构建它们有时从数据库获取let player Player(name: arthur, score: 1000) let players try Player.fetchAll(db)获取到的记录就像数据库内容的内存缓存。应用自行决定如何处理这些缓存值的生命周期忽略未来的变更或观察变更并做出反应。要让视图与数据库内容保持同步可以使用ValueObservation——它在每次数据库变更后通知新鲜值并内置对 Combine 与 RxSwiftRxGRDB的支持/// 一个 [Player] 的观察 let observation ValueObservation.tracking { db in try Player.fetchAll(db) } // 纯 GRDB let cancellable observation.start(in: dbQueue, onError: { error in ... }, onChange: { (players: [Player]) in print(Fresh players) }) // GRDB Combine let cancellable observation.publisher(in: dbQueue).sink( receiveCompletion: { completion in ... }, receiveValue: { (players: [Player]) in print(Fresh players) }) // RxGRDB let disposable observation.rx.observe(in: dbQueue).subscribe( onNext: { (players: [Player]) in print(Fresh playerss) }, onError: { error in ... })在源码层面ValueObservation.tracking默认采用nonConstantRegionRecordedFromSelection追踪模式——被观察的数据库区域由每次 fetch 实际读到的内容推断另有两种常量区域模式constantRegion(_:)与constantRegionRecordedFromSelection适用于被观察区域不随数据变化的场景见 GRDB/ValueObservation/ValueObservation.swift。无论使用哪种观察技术你都得到三重共同保证通知只来自已安全落盘的数据库变更。这是数据库作为单一事实来源原则的体现——你不会收到未保存变更或可能被回滚变更的通知。实现上观察建立在TransactionObserver协议之上该协议在 SQLite 的sqlite3_update_hook、sqlite3_commit_hook等底层回调触发时被驱动见 GRDB/Core/TransactionObserver.swiftdatabaseDidChange(with:)在变更时调用databaseDidCommit(_:)在事务落盘提交后调用。你选择通知发生的调度队列默认一般是主队列如上例。GRDB 保证通知顺序与数据库事务顺序一致。ValueObservation.start支持传入任意的ValueObservationScheduler其中MainActor重载默认使用.mainActor调度器也可改用.immediate让第一个值在启动时立即通知见 ValueObservation.swift。在DatabasePool场景中ValueConcurrentObserver专门维护一条独立的reduceQueue来保证新鲜值通知与事务同序同时避免在计算map、removeDuplicates等归约操作期间锁住数据库见 GRDB/ValueObservation/Observers/ValueConcurrentObserver.swift。所有变更都被通知无论其执行方式记录方法、原生 SQL 语句、外键级联、SQL 触发器。因为 GRDB 把通知系统扎根在稳如磐石的 SQLite 本身高层请求和原生 SQL 查询得到同等支持。2.4 非阻塞的数据库读取DatabaseQueue 与 DatabasePoolGRDB 提供两种访问数据库的方式database queues和database pools对应 DatabaseQueue 与 DatabasePool。DatabaseQueue很像 FMDB 的FMDatabaseQueue在串行派发队列中序列化所有数据库访问任何时刻只有一个线程访问数据库。这意味着后台线程中一个长时间的数据库事务例如从远程服务器同步本地数据库可能阻塞 UI——只要队列繁忙主线程就无法读取它想显示的值。DatabasePool可以解除这些不想要的锁。其核心实现在 GRDB/Core/DatabasePool.swift一个写者SerializedDatabase加一个读者连接池Pool。在池模式下读取通常是非阻塞的除非达到最大并发读数量该最大值可通过Configuration.maximumReaderCount配置构造器中对此有GRDBPrecondition(configuration.maximumReaderCount 0, ...)的约束校验见 DatabasePool.swift。WAL 模式让读者与写者互不阻塞这是 DatabasePool 打开数据库时默认启用 WAL除非只读的原因。2.5 强而清晰的多线程保证四类威胁的对比原文档用四种威胁潜在 bug 来源系统性地比较了各家库的并发能力GRDB 据此论证其保证的清晰度。威胁定义如下并发写入两个线程同时想写数据库。SQLite 不允许这样做。隔离问题两条数据库查询先后执行时一个并发线程在中间插入并修改数据库导致两条查询执行不一致的读取或更新除非它们被正确隔离。缺乏隔离可能在屏幕上显示错误值、触发关系约束错误或静默损坏数据。冲突同一份数据同时被应用用户编辑、又被网络操作刷新。最终写入数据库的是什么冲突能否被发现阻塞 UI主线程是否可能因为等待后台线程释放数据库锁而被阻塞下表完整复现原文档的对比✓ 表示由库处理Handled by the application 表示留给宿主应用处理库并发写入隔离问题冲突阻塞 UIFMDB 的 FMDatabase交给应用交给应用交给应用交给应用FMDB 的 FMDatabaseQueue✓✓交给应用UI 被阻塞SQLite.swift✓交给应用交给应用交给应用Core Data交给应用因为冲突错误的持续威胁✓交给应用且由于 Core Data 冲突策略的微妙之处非常困难交给应用GRDB 的 DatabaseQueue✓✓交给应用UI 被阻塞GRDB 的 DatabasePool✓✓交给应用✓只要未达到最大读者数可以观察到几个关键结论并发写入和隔离问题被 GRDB 的两种连接类型完全处理——DatabaseQueue 通过串行化、DatabasePool 通过写者串行 WAL 并发读的架构冲突处理总是留给应用。Core Data 虽提供冲突策略但没人能声称它们易于规划、使用或测试。这反而成为让应用 100% 负责冲突处理的理由——希望简单冲突能以简单方式处理原生 FMDatabase、SQLite.swift 和 Core Data 是最难的工具只有非常熟练的开发者才能用好它们。原文档也坦诚注明Realm 和 FCModel 未列入表格因为作者对其了解不够充分推测 Realm 与 Core Data 有相似行为FCModel 与 FMDatabaseQueue 有相似行为。GRDB 的完整并发指南见 Documentation/Concurrency.md设计数据库访问层的实践建议可参考 README 的 Records 章节。2.6 永不因使用原生 SQL 而付出代价SQL 是一门诞生于 70 年代的奇怪语言易被误用、被一些开发者畏惧、被另一些轻视却又出奇地简洁强大。GRDB 的立场是记录、查询接口和关联associations可以为你生成 SQL但你随时可以切换回 SQL。使用 Swift 查询接口生成 SQL// UPDATE player SET score 950 WHERE id 42 try player.updateChanges { $0.score 10 } // SELECT * FROM player ORDER BY score DESC LIMIT 10 let bestPlayers: [Player] try Player .order(\.score.desc) .limit(10) .fetchAll(db) // SELECT MAX(score) FROM player let maximumScore: Int? try Player .select { max($0.score) } .asRequestOf(Int.self) .fetchOne(db) // SELECT book.*, author.* // FROM book // LEFT JOIN author ON author.id book.authorId let request Book.including(optional: Book.author) let bookInfos: [BookInfo] BookInfo.fetchAll(db, request)查询接口的完整介绍见 README 的 The Query Interface关联功能见 Documentation/AssociationsBasics.md。随时切回原生 SQLtry db.execute( sql: UPDATE player SET score ? WHERE id ?, arguments: [950, 42]) let bestPlayers: [Player] try Player.fetchAll(db, sql: SELECT * FROM player ORDER BY score DESC LIMIT 10 ) let maximumScore: Int? try Int.fetchOne(db, sql: SELECT MAX(score) FROM player )SQL 插值既自然又安全。SQLInterpolation让你用自然的字符串构建 SQL却没有任何语法错误或 SQL 注入的风险——因为插值内容经类型化处理不会破坏语句结构详见 Documentation/SQLInterpolation.mdtry db.execute(literal: UPDATE player SET score \(score) WHERE id \(id)) extension Player { static func filter(name: String) - SQLRequestPlayer { SELECT * FROM player WHERE name \(name) } } let player try Player.filter(name: Arthur OBrien).fetchOne(db)自定义 SQL 请求同样可以进入数据库观察工具——ValueObservation.tracking的闭包里可以执行任意 SQLlet playerObservation ValueObservation.tracking { db in try Player.filter(name: Arthur OBrien).fetchOne(db) } // 用 Combine 观察 SQL 请求 let cancellable playerObservation.publisher(in: dbQueue).sink( receiveCompletion: { completion in ... }, receiveValue: { (player: Player?) in print(Player has changed) })性能关键区懒游标而非数组。在性能敏感的场景你可以直接面对原始数据库行用懒加载的游标替代数组Cursor的完整说明见 README.md#cursors// 尽量贴近 SQLite 底层 let rows try Row.fetchCursor(db, sql: SELECT id, name, score FROM player) while let row try rows.next() { let id: Int64 row[0] let name: String row[1] let score: Int row[2] }游标逐个加载结果、不占太多内存且被授予对 SQLite 的直接访问权数组和集合则包含数据库值的拷贝取回大量结果时可能占用较多内存。两种形态按需选用正是为应用开发者提供社区验证的高效方案这一原则的体现。三、总结从为什么到开始用回顾四大原则与六大实战议题GRDB 的取舍脉络清晰可循值类型记录 协议扩展让任意 Swift 类型尤其是 struct零继承地获得获取、查询与持久化能力数据库文件作为单一事实来源用落盘后的变更通知替代对象的自动更新将多线程复杂性收拢到库内部两种连接类型Queue 串行 / Pool 并发读把并发写入与隔离问题从应用手里接管让开发者把精力留给真正属于自己的冲突处理SQL 第一公民查询构建器、原生 SQL、SQL 插值、懒游标四者并存按需取用不因框架选择而牺牲 SQLite 的全部能力。如果你想亲自动手验证上述能力可参考仓库内现成的演示工程 Documentation/DemoApps/GRDBDemo含数据库定义与视图层完整示例以及 README 的 Usage 章节的四步启动数据库示例。GRDB 也提供 Combine 支持Documentation/Combine.md、迁移工具Documentation/Migrations.md等应用层设施。若这篇导览已经说服你真正的旅程从 GRDB 官方参考文档的 Database Connections 章节开始。【免费下载链接】GRDB.swiftA toolkit for SQLite databases, with a focus on application development项目地址: https://gitcode.com/GitHub_Trending/gr/GRDB.swift创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考