1、数据库基础与选型：关系型与非关系型数据库对比、SQLite vs MySQL vs PostgreSQL、桌面应用数据库选型原则
做桌面应用开发这么多年，我踩过最大的坑之一，就是数据库选型。说实话，很多人一开始根本不把这当回事——随便选一个，写到一半发现性能扛不住，或者部署时发现用户还得装个数据库服务端，那叫一个头疼。
这一章，咱们就把数据库选型这件事彻底聊透。我会从最基础的概念讲起，然后对比几款主流数据库，最后给出桌面应用的选型原则。嗯，都是实战经验，你拿过去就能用。
1.1 关系型 vs 非关系型：到底怎么选？
先搞清楚这两个阵营的区别。关系型数据库，说白了就是「表格+关系」。你用 Excel 管理数据时，一个 sheet 放客户信息，另一个 sheet 放订单信息，然后用客户 ID 把两张表关联起来——这就是关系型数据库的核心理念。
非关系型数据库呢？它更灵活。你可以存 JSON 文档、键值对、甚至图结构。我早期做过一个配置管理工具，数据格式经常变，用关系型数据库改表结构改到崩溃，后来换成 MongoDB，世界清净了。
核心区别一句话总结：
- 关系型：数据关系明确、需要事务支持、查询复杂——选它
- 非关系型：数据结构灵活、高并发读写、海量数据——选它
但桌面应用场景下，我个人的建议是：优先考虑关系型数据库。为什么？因为桌面应用的数据量通常不大，但数据关系往往很复杂。你想想看，一个进销存系统，商品、客户、订单、入库单……这些数据天然就是关系型的。
我的经验：除非你的数据是纯粹的键值对（比如配置文件缓存），或者文档结构经常变，否则别碰非关系型。我在一个项目中试过用 MongoDB 做桌面应用，结果用户想做个多表关联查询，折腾了半天——得不偿失。
1.2 SQLite vs MySQL vs PostgreSQL：三款主流数据库深度对比
这三款是我在桌面项目中最常用的。咱们一个一个说。
SQLite：轻量级之王
SQLite 是个「嵌入式数据库」。什么意思？它不需要独立的服务进程，数据直接存在一个文件里。你的应用启动时，直接调用 SQLite 的库函数就能读写数据。
我特别喜欢 SQLite 的一点：零配置。用户下载你的软件，双击就能用，不需要安装 MySQL、不需要配置端口、不需要创建用户。对于单机版桌面应用来说，这简直是天选之子。
适用场景：
- 单用户桌面应用（记账软件、笔记工具、个人知识库）
- 移动端应用（Android/iOS 原生支持）
- 嵌入式设备（路由器、智能家居）
- 原型开发（快速验证想法）
但 SQLite 也有短板。并发写入能力弱——多个进程同时写同一个数据库文件，会报错。我记得有一次，一个同事把 SQLite 用在了 Web 服务后端，结果高并发下频繁出现「database is locked」错误。嗯，这就是选型失误。
MySQL：生态最成熟
MySQL 是关系型数据库的老大哥。它需要独立安装服务端，客户端通过网络连接访问。对于需要多用户同时操作的桌面应用，MySQL 是稳妥的选择。
我做过一个连锁店管理系统，每个门店的客户端都连接中心服务器的 MySQL。数据实时同步，权限控制精细，事务支持完善。这种场景下，SQLite 根本扛不住。
注意：MySQL 的安装和配置对普通用户来说是个门槛。如果你的软件需要用户自己装 MySQL，那体验会大打折扣。我建议：要么用 SQLite 做单机版，要么你提供一键部署脚本。
PostgreSQL：功能最强大
PostgreSQL 是关系型数据库里的「技术流」。它支持 JSON、数组、自定义类型、地理空间数据……功能多到让你怀疑它是不是关系型数据库。
我个人习惯在需要复杂查询和数据分析的场景下用 PostgreSQL。比如一个报表系统，需要做窗口函数、递归查询、甚至全文检索——PostgreSQL 都能原生支持，不需要额外插件。
但 PostgreSQL 的缺点是：学习曲线陡。它的配置项比 MySQL 多，性能调优也更复杂。如果你团队里没人熟悉 PostgreSQL，我建议谨慎选择。
| 特性 | SQLite | MySQL | PostgreSQL |
|---|---|---|---|
| 部署方式 | 嵌入式（文件） | 客户端-服务端 | 客户端-服务端 |
| 配置复杂度 | 零配置 | 中等 | 较高 |
| 并发能力 | 弱（单写多读） | 强 | 强 |
| 事务支持 | 支持（但粒度粗） | 支持（InnoDB） | 支持（MVCC） |
| 数据类型 | 基础类型 | 丰富 | 极其丰富 |
| 适用规模 | 单机/小数据量 | 中小型应用 | 中大型应用 |
| 典型场景 | 个人工具、移动端 | Web应用、多用户系统 | 数据分析、GIS、复杂查询 |
1.3 桌面应用数据库选型原则
好了，理论讲完了，咱们来点实际的。我给桌面应用数据库选型总结了四条原则，你照着做，基本不会出大问题。
原则一：优先考虑部署体验
桌面应用和 Web 应用最大的区别是什么？用户不会配置数据库。你想想看，一个普通用户下载了你的记账软件，结果还要去装 MySQL、建数据库、配用户权限——他大概率直接卸载了。
所以我的建议是：能用 SQLite 就用 SQLite。除非你的应用明确需要多用户并发访问，否则别给自己找麻烦。
避坑指南：我曾经做过一个项目，一开始用 SQLite 开发，后来客户要求支持多用户。我花了整整两周把数据迁移到 MySQL，还改了所有 SQL 语句（SQLite 和 MySQL 的 SQL 语法有差异）。如果一开始就选 MySQL，能省一半时间。
原则二：数据量决定一切
你的应用会存多少数据？这是个关键问题。
- 小于 1GB：SQLite 完全够用。我做过一个个人知识管理工具，数据库文件才 200MB，查询速度飞快。
- 1GB - 10GB：可以考虑 MySQL 或 PostgreSQL。这个量级下，SQLite 的查询性能会明显下降。
- 大于 10GB：必须用 MySQL 或 PostgreSQL。而且我建议你考虑分库分表，或者引入缓存层。
原则三：查询复杂度决定数据库类型
如果你的查询很简单——就是根据 ID 查一条记录，或者按条件筛选——那 SQLite 足够了。
但如果你需要做多表 JOIN、子查询、聚合函数、窗口函数……那 PostgreSQL 是更好的选择。MySQL 也能做，但某些复杂查询的性能不如 PostgreSQL。
我记得有一次，一个财务软件需要做「每个月的累计销售额」——这要用到窗口函数的 SUM() OVER (ORDER BY date)。PostgreSQL 原生支持，MySQL 8.0 之后才支持。如果你的用户还在用 MySQL 5.7，那就尴尬了。
原则四：考虑未来的扩展性
很多开发者犯的一个错误：只考虑当前需求。你的应用现在只是单机版，但万一客户要求联网呢？万一需要对接其他系统呢？
我建议：选一个「向上兼容」的数据库。什么意思？
- 先用 SQLite 快速开发，但 SQL 语句尽量写标准 SQL，避免使用 SQLite 特有的语法。
- 在代码中抽象出数据访问层（DAL），这样以后换数据库时，只需要改 DAL 的实现。
- 如果预算允许，直接上 PostgreSQL。它的功能最全，未来扩展空间最大。
我的最终建议：
- 个人工具/小团队内部工具：SQLite（省心、快速）
- 多用户桌面应用（如进销存、CRM）：MySQL（生态好、文档多）
- 需要复杂查询/数据分析的桌面应用：PostgreSQL（功能强、性能稳）
嗯，这一章的内容就到这里。数据库选型没有银弹，关键是根据你的实际场景做权衡。下一章，我会带你手把手搭建 SQLite 的开发环境，并写第一个 CRUD 示例。到时候你就知道，为什么我说 SQLite 是桌面应用开发者的好朋友了。