CouchDB peruser配置下渔船捕捞记录Capacitor应用数据库架构咨询

数据库结构选型 #

推荐直接采用「每船一库」的架构，完全适配你的业务需求，无需使用默认的单人单库peruser配置：

• 所有用户账号统一存在CouchDB系统自带的_users库中，每个用户文档新增自定义字段boat_id标记所属渔船编号
• 每艘渔船对应独立的业务库，库名可按fishing_boat_{唯一船编号}规则命名，库内分两类文档存储业务数据：
  • 行程文档：type: "trip"，存储单次出海行程的基础信息（出海时间、归航时间、作业海域等）
  • 捕捞记录文档：type: "catch_record"，通过trip_id字段关联对应行程，存储单条捕捞的具体数据（品类、重量、位置、时间等），原生支持JSON格式直接写入，无需额外转换

待确认问题解答 #

1. peruser配置问题 #

默认的peruser规则是每个用户分配独立私有库，不同用户的库默认完全隔离，无法低成本实现同船用户的数据共享，不适合你的场景。
调整为「每船一库」的规则完全可行，且不需要全船共享统一凭证：你只需在每个渔船业务库的_security配置文档中，将该船所有授权用户的账号名加入members.names数组，即可实现所有同船用户用个人独立凭证登录后，访问本船的全部业务数据，同时无法访问其他渔船的库，权限隔离符合要求。

2. 身份认证问题 #

优先选择我方后台统一创建所有渔船、用户凭证的方案，从根源上避免在用户端存储任何高权限账号，安全性最高，运维成本也更低。
如果确实有需要支持同船管理员自行新增船员账号的需求，再使用轻量管理员方案：通过_users库的validate_doc_update设计文档规则，限制轻量管理员仅能创建绑定指定boat_id的普通用户账号，无其他库的管理权限，也无法修改/删除其他船的用户和高权限账号，风险完全可控。

3. 代理需求问题 #

上述所有权限控制、数据同步逻辑，全部可以通过CouchDB、PouchDB的原生功能实现，完全不需要在HTTP和CouchDB之间增设额外代理层。移动端PouchDB只需调用PouchDB.authenticate()传入用户个人凭证完成认证后，即可直接和所属渔船的远程CouchDB库做双向同步，符合你的技术选型要求。

该架构同时天然支持离线操作：渔船出海无网络时，用户可以正常在本地录入行程、捕捞数据，联网后自动和远程库同步，无需额外开发同步逻辑。

内容的提问来源于stack exchange，提问作者aanders77