翻译大战：句柄？Handle？

句柄、使能、鲁棒……这些外行人看不懂，内行人听了直摇头的翻译，莫名制造了学习编程的门槛（所以说学编程最好的方式是看英文原著）。

当然写这篇文章的出发点是从实际需求考量的：

当前和账号关联的数据之前是单独存在一个DB的，现在我们的业务要做多账号。
那么问题来了：
方案一：每个账号都使用一个表
方案二：多个账号存到同一个表里，做好数据的迁移

同事方向技术时说了方案二，原因是多句柄开销较大。

我是知道句柄会有一定开销，但开销有多大之前没有研究过，所以今天聊聊数据库句柄相关的内容，主要分3个方面：

1
2
3

1. 什么是句柄
2. 数据库句柄使用
3. 句柄开销问题

一、什么是句柄

句柄英文原文叫 handle，有提手、把手的意思。

door handle 是门把手，通过 door handle 可以操作 door

knife handle 是刀柄，通过刀柄可以使用刀

所以可以把 handle 理解为中间媒介，通过这个媒介可以控制、操作某样东西。

handle本身是一种”闭·开”的设计思想，door的功能很丰富，但不能把door的所有细节都暴露给开发者，所以通过 door handle，告诉开发者应该如何使用 door。

在iOS中系统提供了sqlite3数据库，sqlite3是一种类型，db是数据库的句柄，就是数据库的象征，如果要进行增删改查，就得操作db这个实例。

查看沙盒内创建的数据库文件：

双击打开，查看发现打开的数据库连接名称为students,默认为文件名的前缀，数据库创建成功。

回到开篇提到的问题：

当前和账号关联的数据之前是单独存在一个DB的，现在我们的业务要做多账号。
那么问题来了：
方案一：每个账号都使用一个表
方案二：多个账号存到同一个表里，做好数据的迁移

同事方向技术时说了方案二，原因是多句柄开销较大。

我们内部使用的是 WCDB 的方案，每个表的读写对应的数据结构是：WCTTable。

如果采用方案一，会有两个问题：

首先鉴于多账号是用户使用时动态创建的，如果采用一个账号对应一个 WCTTable，那就需要动态创建WCTTable，数据库操作尽可能要保持稳定，不要执行runtime的行为。

其次用户层面是多账号，但实际上同一时刻用户只可能使用一个账号，那么在初始化DB阶段，如果一次性将所有账号存储的WCTTable句柄都构建出来，相当于会有浪费使用不到的句柄。

本文从句柄的翻译问题出发，聊了句柄的使用和开销问题，并为多账号的方案提供了可行的参考。

后续使用时，也要考虑到句柄的开销问题，如果一个数据无需频繁读写，那么写进MMKV文件会使一个比较好的选择。