基于PocketBase的媒体追踪应用：Class Table Inheritance选型咨询

这个方案完全可行，非常适配你当前的场景——各类媒体共享大量属性、仅少量字段差异化。具体落地方式是：

• 建一张核心media表，存储所有媒体的共同字段：比如唯一ID、标题、消费状态（已看/在读等）、评分、创建时间、更新时间等。
• 为每种媒体类型单独建子表（如movies、books、comics），子表用外键关联media表的ID，只存储该类型的特有字段：比如movies存时长、导演；books存作者、页数；series存季数、集数。

这种模式严格遵循第三范式，数据冗余极低，扩展性强——新增媒体类型时只需添加对应子表，不会影响现有表结构，也能保证各类型数据的完整性约束。

针对你的场景，主要有两种替代方向，各有优劣：

1. 混合模式（核心表+JSON元数据字段）
   在media表中新增一个metadata JSON字段，用来存储各媒体类型的特有属性（比如电影的时长、导演直接存在JSON里）。这种模式的优势是无需创建多个子表，避免JOIN操作，开发速度快，PocketBase和SQLite对JSON字段的支持都很完善；缺点是JSON字段的查询性能弱于原生字段，难以对特有属性建索引，也无法通过数据库约束保证数据格式的正确性（比如无法强制要求metadata里的duration必须是数字）。适合追求快速迭代、对数据约束要求不高的个人项目。

2. 单表继承（Single Table Inheritance）
   把所有媒体的字段都放在一张media表里，新增一个type字段标记媒体类型（movie/book等），非该类型的字段留空。这种模式的优点是查询时无需JOIN，操作简单；但缺点很明显——大量空字段违反第三范式，表结构会随着媒体类型增加变得臃肿，数据约束难以维护，只适合媒体类型差异极小的场景，对你的需求来说不是最优解。

至于EAV（实体-属性-值）模型，完全不推荐，它会导致查询逻辑极度复杂，性能低下，只适用于属性极多且不确定的场景，和你的需求不匹配。

你担心的JOIN性能问题在个人项目中其实不会太突出（毕竟数据量不会达到企业级规模），但可以通过以下手段进一步优化：

• 强制给外键字段建索引：SQLite不会自动为外键创建索引，所以要手动给子表的外键字段（比如movies.media_id）添加索引。在PocketBase后台编辑子表时，直接在字段设置里开启索引即可，这能大幅提升JOIN操作的速度。
• 按需查询，避免全字段拉取：查询时只请求需要的字段，比如查电影时，只取media表的标题、评分，加上movies表的时长、导演，不要用SELECT *拉取所有字段，减少数据传输和处理开销。
• 利用PocketBase的关联查询能力：PocketBase的API原生支持关联查询，比如通过GET /api/collections/media/records?expand=movies可以直接获取关联的电影数据，底层已经做了JOIN优化，比自己写复杂SQL更高效。
• 创建常用视图：可以在SQLite中创建联合视图，把media表和对应子表的常用字段合并，比如：

  CREATE VIEW movie_media AS 
  SELECT m.id, m.title, m.rating, mv.duration, mv.director 
  FROM media m 
  JOIN movies mv ON m.id = mv.media_id 
  WHERE m.type = 'movie';
  

  查询时直接调用视图，简化操作的同时，SQLite会自动优化视图的执行计划。
• 缓存高频数据：对于经常访问的媒体列表（比如已完成的电影），可以在客户端做本地缓存，或者利用PocketBase的内置缓存机制，减少重复查询数据库的次数，间接降低JOIN的频率。
• 分页查询：当数据量逐渐增加时，一定要用分页查询（PocketBase API支持page和perPage参数），避免一次性拉取大量数据，单次JOIN的开销会显著降低。

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