基于PixiJS渲染族谱的数据结构、数据库与API选型咨询

一、数据结构选型 #

闭包表模型（优先推荐） #

• 精准解决邻接表、嵌套集的核心痛点：完美支持复杂婚姻关系（再婚、多配偶等），可轻松存储未知父母的家族成员，深树查询（如获取某成员所有直系祖先/后代）效率远高于邻接表。
• 实现逻辑：采用双表结构
  • members表：存储成员基础信息（id, name, birth_date, notes等字段）
  • closure表：存储血缘关系路径（ancestor_id, descendant_id, depth），查询某成员的所有直系祖先时，直接筛选descendant_id = 目标ID的记录即可；新增marriages表（id, spouse_a_id, spouse_b_id, marriage_date）单独管理婚姻关系，避免与血缘关系混淆。

备选：图数据模型（适合后期扩展） #

如果后续需要支持收养、旁系亲属关联查询等更复杂的关系场景，图结构的「节点-边」模型天然适配——每个家族成员是节点，父母、配偶、子女等关系是带属性的边，无需额外设计关系表，遍历查询效率更高。

二、数据库选型 #

优先推荐：SQLite + 闭包表 #

• 核心优势：轻量无服务器，部署成本为零，完全适配数千条数据的规模；闭包表的SQL查询逻辑成熟，开发门槛低，适合家族成员小范围使用的场景。
• 扩展方案：若后续需要多人协作访问，可将SQLite文件托管至云存储，或平滑迁移至MySQL。

备选：Neo4j（图数据库） #

• 适用场景：如果需要频繁执行复杂亲属关系查询（如「某成员的所有堂兄妹」），图数据库的遍历效率远高于SQL；缺点是学习成本略高，部署复杂度比SQLite高。

不推荐：文档型数据库 #

族谱属于强关系型数据，文档库的嵌套结构在处理跨文档关系查询时会极度低效，完全不适配这类场景。

三、API架构选型 #

优先推荐：分场景选择方案 #

• 本地桌面端场景：用Electron封装PixiJS前端，直接读取本地SQLite文件，无需额外API，开发速度最快，适合家族内部小范围使用。
• Web端多人访问场景：采用S3托管静态前端 + AWS AppSync GraphQL服务
  • 优势：GraphQL的按需查询特性完美匹配PixiJS的渲染需求（仅加载当前画布可见区域的成员数据），减少无效网络请求；托管方案无需自行维护服务器，运维成本极低。

备选：Docker部署REST API #

若对云服务有顾虑，可基于Ubuntu Docker镜像部署Node.js/Java开发的REST API，对接MySQL/SQLite；但需自行维护服务器，开发量比GraphQL方案大，前端也需要编写更多请求逻辑。

四、落地步骤建议 #

1. 先完成OCR数据提取，整理成结构化的成员、关系数据，用「闭包表+SQLite」搭建最小原型，验证查询与渲染逻辑。
2. 原型验证通过后，根据访问需求决定是否迁移至云托管GraphQL方案或图数据库。
3. 始终将婚姻关系与血缘关系分开存储，方便PixiJS渲染时区分配偶节点与亲属节点。

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