SQL 02：起底 Kitsu 资产管理系统的 PostgreSQL 后端数据表结构

前言

在上一篇 SQL 01 中，我们用 Python + SQLite 模拟搭建了一个好莱坞式的多表关联资产库。有人可能会问：“大厂真正用起来的系统也是这样的吗？我直接用开源的 Kitsu 资产管理系统，是不是就不用理会底层数据库了？”

答案是：你依然逃不掉，而且这正是体现 Pipeline TD 核心价值的地方。

Kitsu 的本质只是一个漂亮的 Web 浏览器前端，它背后的亲生骨肉叫 Gazu（Python API），而它们赖以生存的所有资产、镜头、任务数据，100% 全都存储在底层的 PostgreSQL 关系型数据库中。

今天这一篇，我们不写一行业务代码，直接带大家通过数据库可视化工具（如 DBeaver），“外科手术式”地切入 Kitsu 的 PostgreSQL 后端，看看国际一线管线是如何组织核心数据结构的。

---

一、 Kitsu 底层最核心的 5 张 SQL 数据表

当你用 Docker 部署好 Kitsu 后，连入它的 PostgreSQL 数据库，你会看到几百张表，但支撑起整个大项目 CG 流程的，其实是以下这 5 张核心表：

1. projects（项目表）： 存储所有电影、剧集、游戏项目的总表。
2. episodes（剧集表）与 sequences（场次表）： 组织镜头的上级结构。
3. shots（镜头表）： 整个制作流程的灵性核心。
4. assets（资产表）： 存储角色、道具、场景等数字资产。
5. tasks（任务表）： 纽带表，记录每个镜头或资产在各个环节（Layout, Anim, Lighting）的制作状态。

---

二、 源码级拆解：大厂是如何利用外键（Foreign Key）连接世界的？

Kitsu 为什么在大数据量下绝对不会出现“找不到资产所属镜头”的低级 Bug？因为它的表结构设计死死遵守了我们在第一篇学到的外键约束。

我们用原生的 SQL 语法来还原 Kitsu 底层这两张最关键的表的精妙设计：

1. 镜头表 (shots) 的工业设计

CREATE TABLE shots (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- 使用 UUID 代替递增自增ID，防止多服务器分布式同步冲突
    name VARCHAR(255) NOT NULL,                    -- 镜头号，如 "chk01"
    sequence_id UUID NOT NULL,                     -- 属于哪个场次
    frame_in INTEGER,                              -- 起始帧
    frame_out INTEGER,                             -- 结束帧
    project_id UUID NOT NULL,                      -- 属于哪个项目

    -- 外键约束：如果项目或者场次在各自的表里被干掉了，数据库直接拒绝或联动
    FOREIGN KEY (project_id) REFERENCES projects(id),
    FOREIGN KEY (sequence_id) REFERENCES sequences(id)
);

2. 万能纽带：任务表 (tasks) 的设计

在 Kitsu 里，无论是给“角色资产”派发任务，还是给“特效镜头”派发任务，它们并没有分别为镜头和资产建两张任务表，而是极其优雅地合并成了一张 tasks 表：

CREATE TABLE tasks (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    task_type_id UUID NOT NULL,         -- 任务环节（如 Animation, Lighting）
    task_status_id UUID NOT NULL,       -- 当前状态（如 Todo, WIP, Approved）
    assignee_id UUID,                   -- 指派给哪位艺术家的用户ID

    -- 核心：双实体外键挂靠（可选空）
    entity_id UUID NOT NULL,            -- 指向资产ID，或者镜头ID（在 Kitsu 统一抽象为 Entity）
    project_id UUID NOT NULL,

    FOREIGN KEY (project_id) REFERENCES projects(id)
);

---

三、 TD 实战：不通过 API，直接用 SQL 完成降维打击

当项目进入中期，数据量暴增。如果总监找你要一个极其复杂的报表，通过 Python API 循环遍历可能会让服务器直接卡死。这时懂 SQL 的 TD 可以直接进数据库后台进行降维打击。

核心技能：一键抓出“全项目 Lighting 环节被 Reject 超过 3 次的重度镜头”

如果用 Python API 写，你需要获取所有镜头，再循环获取每个镜头的任务，再过滤状态。而在 PostgreSQL 里面，直接用一条 多表联查（JOIN）+ 分组聚合（GROUP BY） 搞定：

SELECT 
    s.name AS shot_name, 
    COUNT(t.id) AS reject_count
FROM tasks t
INNER JOIN shots s ON t.entity_id = s.id
INNER JOIN task_statuses ts ON t.task_status_id = ts.id
INNER JOIN task_types tt ON t.task_type_id = tt.id
WHERE tt.name = 'Lighting' AND ts.name = 'Rejected'
GROUP BY s.name
HAVING COUNT(t.id) >= 3
ORDER BY reject_count DESC;

为什么这招无敌？ 数据库底层对 INNER JOIN 和索引做了极致的机器级优化。通过网页或 API 跑需要几分钟的统计，这条 SQL 语句在底层可能只需要 5 毫秒 就能瞬间吐出结果。

---

四、 总结与站长寄语

看懂了 Kitsu 的底层，你就会明白：世上本没有资产管理系统，只有一堆设计精妙的 SQL 数据表和外键。 Kitsu 帮我们封装好了华丽的外壳，但作为 Pipeline TD，我们要有穿透外壳直达底层的能力。当 Kitsu 崩溃、Docker 损坏导致数据损坏时，你能熟练地用 pg_dump 修复、备份它，或者用 SQL 语句做紧急数据修正，这才是在工业生产中真正让人放心的硬实力。

下一篇，我们将暂时告别纯技术理论，带来更硬核的服务器运维实战：《SQL 03：基于 Linux Docker 快速拉起 Kitsu 服务与 PostgreSQL 生产级定时备份配置》。敬请期待！

---