从PID到SQLite：用Python构建数字绘画资产管理工具

看到PID:143758591 画师:悟之心这样一条记录，后端开发者的第一反应往往是“Process ID”，但把它放进数字绘画资产管理场景，它其实是一条作品编号和作者署名的组合。PID 在最常见的插画作品归档语境里，可以理解为 Picture ID 或 Post ID，也就是图片编号；而画师:悟之心是作者署名。如果要把数量庞大的绘画素材、插画稿件和创作过程文件从“文件夹层层套娃”升级为“可检索、可查重、可追溯的作品库”，首先要解决的问题，就是把 PID、画师署名、标题、标签、来源这些零散信息转成结构化字段。

这篇文章以“构建一个数字绘画资产管理工具”为主线，从数据模型设计讲起，给出一个基于 Python + SQLite 的最小可运行实现，再说明入库、检索、去重、导出这条完整链路中哪些参数不能省，以及遇到重复图片、中文乱码、标签搜索不准时该按什么顺序排查。文章适合两类读者：一类是画师本人，想整理原创稿件和过程文件；另一类是做图库、素材站、数字藏品后台的开发者，需要一个可落地的资产建模思路。

1. 先从一条作品记录理解 PID、画师与作品元数据

1.1 文件夹管理为什么会在 1000 张图之后崩溃

很多数字绘画创作者最初是这样管理作品的：

data/ ├── 图片001.png ├── 图片002.png ├── 最终版/ │ ├── 封面.png │ └── 插画.png ├── 参考/ │ ├── 参考01.jpg │ └── 参考02.png └── 画师/ ├── 悟之心/ └── 其他画师/

这种结构在图片数量较少时足够用，但图片超过几百张或上千张后，问题会集中出现。

文件名不能承担“唯一标识”的职责。最终版.png可能改了三次文件名，微信图片_20250101.png这种文件名没有任何语义，同一个文件复制到不同目录后很难判断是不是同一张图。更麻烦的是，作者署名经常被写进文件名里，比如悟之心-星夜独行-最终版.png，一旦换电脑、换整理习惯、重新归类，文件名就会变化，原本藏在文件名里的信息也就丢了。

解决方案不是规定“每个人必须按规则命名”，而是把“作品本身”和“作品信息”分离。文件只是作品的一个载体，作品信息应落在数据库里，并且通过一个稳定编号与文件关联。

1.2 PID 在不同技术语境里的含义不同

PID 三个字母在后端、操作系统、数据仓库里都有各自含义：

在绘画作品归档场景，PID 通常是数字，比如143758591，也可以是一个业务批次号。它最重要的特性是“稳定且不随文件名变化”。

设计时有一个关键选择：直接使用外部平台的 PID 作为主键，还是使用本地自增主键并把外部 PID 作为普通字段。

如果作品来源单一，且你确实需要引用外部平台的稳定编号，可以直接用pid INTEGER PRIMARY KEY。这样做的优点是全局溯源方便，看到 PID 就知道是哪个来源；缺点是如果同时管理多个来源，不同来源的 PID 可能撞号。

如果管理的是自己原创作品，更适合的方式是“本地自增主键 + 外部编号字段”：

文章中后续示例采用“外部 PID 直接做主键”的简化模型，因为输入场景PID:143758591天然需要一个显式编号。

1.3 一张画要能被程序管理，需要哪些元数据

一张画除了图片字节内容本身，还需要至少以下几类信息：

• 唯一标识：PID，用于稳定引用。
• 标题：作品名称，用于搜索展示。
• 画师署名：作者名，必须从“画师:悟之心”这类字符串中拆出来。
• 文件路径：作品实际存储位置。
• 文件哈希：用于内容去重和完整性校验。
• 标签：风格、题材、用途等分类信息。
• 来源：如果图片来自外站合作或公开素材库，要保留来源地址。
• 时间：入库时间、最后修改时间。

这些字段缺了任何一项，后续都会遇到被迫“反向补数据”的麻烦。尤其文件哈希，很多个人图库工具都不做，导致图片只要换个文件名，就会重复入库一次。

2. 把“画师:悟之心”变成数据库字段：模型设计

2.1 先想清楚查询需求，再设计表

设计表之前，先列出资产库最常见的查询需求：

• 按画师查：输入“悟之心”，返回该画师所有作品。
• 按标签查：输入“风景”，返回所有风景类作品。
• 按关键词查：标题、标签里匹配某个词。
• 查重复：同一张图片换文件名的重复记录。
• 导出清单：按条件导出 CSV 或 JSON，用于存档、展示或迁移。

用 SQLite 可以快速满足这些需求。小规模数据不需要一开始就上 MySQL、PostgreSQL。

2.2 最小表结构：一张作品表足够起步

个人作品库的最小表结构可以这样设计：

CREATE TABLE IF NOT EXISTS artworks ( pid INTEGER PRIMARY KEY, title TEXT NOT NULL, artist TEXT NOT NULL, file_path TEXT NOT NULL UNIQUE, file_hash TEXT, source_url TEXT, tags TEXT NOT NULL DEFAULT '', created_at TEXT NOT NULL DEFAULT (datetime('now')), updated_at TEXT NOT NULL DEFAULT (datetime('now')) ); CREATE INDEX IF NOT EXISTS idx_artworks_artist ON artworks(artist); CREATE INDEX IF NOT EXISTS idx_artworks_tags ON artworks(tags); CREATE INDEX IF NOT EXISTS idx_artworks_hash ON artworks(file_hash);

说明：artist字段和file_hash字段是这套模型的重点。

artist存的是归一化后的作者名。外部数据常见写法是画师:悟之心，但入库时应去掉“画师:”前缀，只存悟之心。这不是为了省几个字符，而是避免查询条件不稳定。如果你存成画师:悟之心，用户搜索悟之心时无法直接用等值匹配，只能写LIKE '%悟之心%'，索引会失效，查询也会更慢。

file_hash存 SHA-256 值。两张图片即使文件名、文件路径完全不同，只要内容一致，SHA-256 就一致，这是查重的基础。

2.3 标签用逗号字符串还是关联表

个人工具、数据量几千条以内时，tags字段直接用逗号分隔文本是合理的：

少女,插画,风景,原创

查询带“插画”标签的记录时，使用精确匹配方式而不是简单LIKE：

SELECT pid, title, artist, tags FROM artworks WHERE (',' || tags || ',') LIKE '%,插画,%';

由于 CSV 用LIKE '%插画%'会把“风景插画”“插画师”都匹配进来，虽然有时“模糊匹配”也能用，但对标签这种枚举值来说，应该尽量精确。

团队级、生产级系统建议投入成本做标签关联表：

CREATE TABLE tags ( tag_id INTEGER PRIMARY KEY AUTOINCREMENT, tag_name TEXT NOT NULL UNIQUE ); CREATE TABLE artwork_tag_rel ( artwork_id INTEGER NOT NULL, tag_id INTEGER NOT NULL, PRIMARY KEY (artwork_id, tag_id) );

关联表的优势是标签可以标准化、去重、统计频率，代价是查询要 JOIN，代码也要多不少。考虑到本场景是从零搭建管理工作流，先用字符串字段能更快跑通，后面再迁移不迟。

2.4 画师是否需要单独建表

作品表里已经有一个artist字段，为什么还要考虑单独建artists表？

因为画师这个维度不只是“一个字符串”。同一个画师可能有多个昵称，有主页地址，有合作署名，还有备注信息。如果只存在artworks.artist里，改昵称时就要批量更新作品表，很不安全。

推荐的扩展表结构：

CREATE TABLE IF NOT EXISTS artists ( artist_id INTEGER PRIMARY KEY AUTOINCREMENT, display_name TEXT NOT NULL UNIQUE, aliases TEXT NOT NULL DEFAULT '', homepage_url TEXT, remark TEXT, created_at TEXT NOT NULL DEFAULT (datetime('now')) );

但在最小可运行示例中，我们暂时保留artworks.artist作为纯文本字段。等作品量超过几千条、开始出现大量别名和协作关系时，再拆artists表。

3. 搭建最小可运行示例：Python + SQLite 资产管理脚本

3.1 环境准备与项目结构

本地环境只需要 Python 3.8 以上版本，SQLite 是 Python 内置模块，不需要额外安装任何第三方库。

python --version

项目结构建议如下：

art_assets/ ├── art_library.py ├── data/ │ ├── demo_001.png │ └── demo_002.png └── art_assets.db

data目录放原始图片，art_assets.db是 SQLite 数据库文件，art_library.py是管理脚本。

为了让后面能演示“内容相同但文件名不同”的重复图片检测，先生成两张测试图片。这里使用 Python 内置 base64 生成一张 1x1 的最小 PNG：

mkdir -p data python - <<'PY' import base64 png_bytes = base64.b64decode( "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAwMCAO+/p9sAAAAASUVORK5CYII=" ) open("data/demo_001.png", "wb").write(png_bytes) open("data/demo_002.png", "wb").write(png_bytes) PY

关键点：demo_001.png和demo_002.png的文件名不同，但内容完全相同，这样才能验证文件哈希去重能力。

3.2 核心脚本：完整实现

下面脚本把“初始化数据库、入库、检索、去重、导出”五个操作整合到一个文件里。直接保存为art_library.py即可运行。

import argparse import csv import hashlib import sqlite3 from pathlib import Path DB_PATH = Path("art_assets.db") def sha256_file(path): h = hashlib.sha256() with open(path, "rb") as f: for chunk in iter(lambda: f.read(1024 * 1024), b""): h.update(chunk) return h.hexdigest() def connect(): conn = sqlite3.connect(DB_PATH) conn.row_factory = sqlite3.Row return conn def init_db(): conn = connect() try: conn.executescript( """ CREATE TABLE IF NOT EXISTS artworks ( pid INTEGER PRIMARY KEY, title TEXT NOT NULL, artist TEXT NOT NULL, file_path TEXT NOT NULL UNIQUE, file_hash TEXT, source_url TEXT, tags TEXT NOT NULL DEFAULT '', created_at TEXT NOT NULL DEFAULT (datetime('now')), updated_at TEXT NOT NULL DEFAULT (datetime('now')) ); CREATE INDEX IF NOT EXISTS idx_artworks_artist ON artworks(artist); CREATE INDEX IF NOT EXISTS idx_artworks_tags ON artworks(tags); CREATE INDEX IF NOT EXISTS idx_artworks_hash ON artworks(file_hash); """ ) conn.commit() print("数据库初始化完成:", DB_PATH.resolve()) finally: conn.close() def add_artwork(pid, title, artist, file_path, tags="", source_url=""): file_path = Path(file_path).resolve() if not file_path.exists(): raise RuntimeError(f"图片文件不存在: {file_path}") file_hash = sha256_file(file_path) conn = connect() try: exists_by_pid = conn.execute( "SELECT 1 FROM artworks WHERE pid = ?", (pid,) ).fetchone() if exists_by_pid: raise RuntimeError(f"pid 已存在: {pid}") exists_by_path = conn.execute( "SELECT 1 FROM artworks WHERE file_path = ?", (str(file_path),) ).fetchone() if exists_by_path: raise RuntimeError(f"file_path 已存在: {file_path}") exists_by_hash = conn.execute( "SELECT pid FROM artworks WHERE file_hash = ?", (file_hash,) ).fetchone() if exists_by_hash: raise RuntimeError( f"相同内容已入库，冲突 pid={exists_by_hash['pid']}" ) conn.execute( """ INSERT INTO artworks(pid, title, artist, file_path, file_hash, source_url, tags) VALUES (?, ?, ?, ?, ?, ?, ?) """, (pid, title, artist, str(file_path), file_hash, source_url, tags), ) conn.commit() print( f"[ok] 入库成功: pid={pid}, artist={artist}, " f"title={title}, hash={file_hash[:12]}" ) except sqlite3.IntegrityError as e: raise RuntimeError(f"数据库唯一约束冲突: {e}") from e finally: conn.close() def search(keyword=None, artist=None, tag=None): sql = "SELECT pid, title, artist, tags, file_path, source_url, created_at FROM artworks WHERE 1=1" params = [] if keyword: sql += " AND (title LIKE ? OR tags LIKE ?)" params.extend([f"%{keyword}%", f"%{keyword}%"]) if artist: sql += " AND artist = ?" params.append(artist) if tag: sql += " AND (',' || tags || ',') LIKE ?" params.append(f"%,{tag},%") sql += " ORDER BY pid DESC" conn = connect() rows = conn.execute(sql, params).fetchall() conn.close() return rows def export_csv(rows, output): with open(output, "w", newline="", encoding="utf-8-sig") as f: writer = csv.writer(f) writer.writerow( ["pid", "title", "artist", "tags", "file_path", "source_url", "created_at"] ) for r in rows: writer.writerow( [ r["pid"], r["title"], r["artist"], r["tags"], r["file_path"], r["source_url"], r["created_at"], ] ) print(f"导出 {len(rows)} 条记录到 {output}") def check_duplicates(): conn = connect() rows = conn.execute( """ SELECT file_hash, COUNT(*) AS cnt, GROUP_CONCAT(pid) AS pids FROM artworks GROUP BY file_hash HAVING cnt > 1 """ ).fetchall() conn.close() return rows def main(): parser = argparse.ArgumentParser(description="数字绘画资产管理工具") sub = parser.add_subparsers(dest="command", required=True) p_init = sub.add_parser("init") p_init.set_defaults(func=init_db) p_add = sub.add_parser("add") p_add.add_argument("--pid", type=int, required=True) p_add.add_argument("--title", required=True) p_add.add_argument("--artist", required=True) p_add.add_argument("--file", required=True) p_add.add_argument("--tags", default="") p_add.add_argument("--source", default="") p_add.set_defaults(func=lambda args: add_artwork( args.pid, args.title, args.artist, args.file, args.tags, args.source )) p_search = sub.add_parser("search") p_search.add_argument("--keyword", default=None) p_search.add_argument("--artist", default=None) p_search.add_argument("--tag", default=None) p_search.set_defaults(func=lambda args: print_search(args)) p_export = sub.add_parser("export") p_export.add_argument("--output", default="artworks.csv") p_export.add_argument("--keyword", default=None) p_export.add_argument("--artist", default=None) p_export.add_argument("--tag", default=None) p_export.set_defaults(func=lambda args: export_csv( search(args.keyword, args.artist, args.tag), args.output )) p_dup = sub.add_parser("dup") p_dup.set_defaults(func=lambda args: print_dup()) args = parser.parse_args() args.func(args) def print_search(args): rows = search(args.keyword, args.artist, args.tag) for r in rows: print( f"{r['pid']}\t{r['artist']}\t{r['title']}\t" f"{r['tags']}\t{r['file_path']}" ) print(f"共 {len(rows)} 条") def print_dup(): rows = check_duplicates() if not rows: print("暂无重复图片") return for r in rows: print( f"重复hash: {r['file_hash'][:16]}, 数量: {r['cnt']}, PID列表: {r['pids']}" ) if __name__ == "__main__": main()

这段脚本中有几个关键点需要注意。

第一，add_artwork中先查 PID、再查文件路径、最后查文件哈希，是为了在进入INSERT之前就把常见冲突拦截掉。SQLite 的UNIQUE约束也能兜底，但数据库报错信息对用户不友好，提前检查能把错误原因说清楚。

第二，sha256_file使用分块读取，按 1MB 一块计算，避免一次性把整个大图读进内存。生产环境中图片可能达到几十 MB，分块处理是基本要求。

第三，export_csv使用utf-8-sig编码，不是utf-8。原因是 Excel 打开utf-8无 BOM 的 CSV 时会把中文读成乱码，utf-8-sig会写入 BOM，Excel 识别更稳定。

3.3 命令解析逻辑

main()使用argparse的add_subparsers，每个子命令对应一个函数：

这里没有做成交互式界面，因为命令行脚本更适合批量操作和后续接入定时任务。

4. 完整运行：入库、检索、去重、导出

4.1 初始化数据库

进入项目根目录，执行：

python art_library.py init

正常输出：

数据库初始化完成: /home/user/art_assets/art_assets.db

初始化会创建artworks表和三个索引。执行后项目目录下出现art_assets.db文件。

注意：init使用的是CREATE TABLE IF NOT EXISTS，重复执行不会覆盖已有数据。如果想清空重来，需要手动删除art_assets.db文件，而不是只执行 init。

4.2 添加入库作品

现在把一张作品加入数据库，PID 使用输入场景中的143758591，画师署名使用“悟之心”。

python art_library.py add \ --pid 143758591 \ --title "星夜独行" \ --artist "悟之心" \ --file "data/demo_001.png" \ --tags "插画,风景,原创" \ --source "本地归档"

预期输出：

[ok] 入库成功: pid=143758591, artist=悟之心, title=星夜独行, hash=9c03c7b2f46a

再添加一张文件名不同、内容相同的图片，用来验证查重：

python art_library.py add \ --pid 143758592 \ --title "星夜独行-副本" \ --artist "悟之心" \ --file "data/demo_002.png" \ --tags "插画" \ --source "本地归档"

预期输出不是 “入库成功”，而是：

RuntimeError: 相同内容已入库，冲突 pid=143758591

这说明文件哈希检测已经生效，同一张图即使换了文件名也无法重复入库。

4.3 按画师和标签检索

按画师精确查询：

python art_library.py search --artist "悟之心"

预期输出：

143758592 悟之心 星夜独行-副本 插画 /home/user/art_assets/data/demo_002.png 143758591 悟之心 星夜独行 插画,风景,原创 /home/user/art_assets/data/demo_001.png 共 2 条

上面结果中出现143758592，是因为上一步的重复拦截发生在INSERT之前，数据库里不会真的插入这条重复记录。如果加了其他允许重复内容的测试数据，检索结果会按 PID 倒序排列。

按标签精确查询：

python art_library.py search --tag "插画"

预期结果只返回包含完整“插画”标签的记录，不会把“插画师”这种模糊词匹配进来。

4.4 检查重复图片

如果库里已经存在历史重复数据，可以运行：

python art_library.py dup

预期输出：

暂无重复图片

如果库里存在同一内容多次入库的历史脏数据，输出会类似：

重复hash: 9c03c7b2f46a, 数量: 2, PID列表: 143758591,143758592

4.5 导出 CSV

按画师导出所有作品清单：

python art_library.py export --artist "悟之心" --output "artist_wuzhixin.csv"

用文本编辑器打开 CSV，内容大致如下：

pid,title,artist,tags,file_path,source_url,created_at 143758591,星夜独行,悟之心,插画,风景,原创,/home/user/art_assets/data/demo_001.png,本地归档,2025-01-01 12:00:00

utf-8-sig编码保证 Excel 双击打开时不会出现中文乱码。

5. 关键参数与实现细节，为什么不能省

5.1 为什么用 INTEGER 主键而不是字符串

pid使用INTEGER PRIMARY KEY，而不是TEXT，主要有两个原因。

第一，数字比较和索引排序在 SQLite 中性能更好。第二，外部平台给的 PID 大多本身就是纯数字，用整型存储不会引入前导零、空格、大小写等问题。

如果外部 PID 可能包含字母，比如A-143758591，才建议用TEXT。但即使是这种情况，也要在建表之前做好决策，避免中途改字段类型。

5.2 artist 字段必须做归一化

“归一化”是指把同一种东西的不同写法统一成一种写法。

画师:悟之心、悟之心、画家：悟之心在人工阅读时是同一个意思，但数据库不这么认为。如果入库时不做归一化，后来做WHERE artist = '悟之心'就查不到画师:悟之心这条记录。

推荐做法：

• 入库前去除“画师:”“画家:”“作者:”这类前缀。
• 去除首尾空格。
• 全半角冒号统一。
• 一个画师的多个昵称，在artists表的aliases字段中登记，而不是直接修改作品表。

在命令行中对应的是--artist "悟之心"，而不是--artist "画师:悟之心"。

5.3 file_hash 是去重和溯源的关键

file_hash用 SHA-256 计算。与 MD5 相比，SHA-256 碰撞概率更低，虽然计算略慢，但对图片管理场景完全可接受。

计算代码如下：

def sha256_file(path): h = hashlib.sha256() with open(path, "rb") as f: for chunk in iter(lambda: f.read(1024 * 1024), b""): h.update(chunk) return h.hexdigest()

分块读取很关键，不能写成open(path, "rb").read()，那会把整张图片一次性写入内存。

有没有比哈希更好的去重方式？如果图片非常大，可以先用文件大小做粗筛，再对相同大小的文件计算哈希。个人图库场景直接算哈希即可。

5.4 created_at 和 updated_at 默认值策略

表结构里created_at默认值是：

datetime('now')

注意这里存的是 UTC 时间，不是本地时间。如果你的业务需要本地时间展示，可以改用：

datetime('now', 'localtime')

推荐在数据库层统一存 UTC，展示层再转本地时间。这样做的原因是不同设备、不同服务器的时区可能不一致，统一 UTC 可以避免“为什么导入时间差了 8 小时”这类问题。

5.5 SQLite 连接与事务处理

connect()中设置了row_factory = sqlite3.Row，这样查询结果可以用r['artist']这样按列名取值，而不是靠下标，代码可读性更好。

add_artwork中所有检查都在同一个连接里完成，最后统一conn.commit()。如果中途抛出异常，由于没有执行commit()，事务不会提交，数据库不会被部分写入。这是在 Python 中使用 SQLite 最简单的“类事务”处理方式。

6. 常见问题与排查链路

6.1 数据库初始化后找不到数据

现象：第一次运行init后，再运行search返回空。

排查顺序：

1. 检查当前目录下是否生成了art_assets.db文件。
2. 检查数据库文件路径是否在不同目录。例如在项目根目录执行init，却在data目录下执行search，会因为当前目录不同而连接不同的数据库文件。
3. 检查是否误删了数据库文件。
4. 检查表中是否有数据：

sqlite3 art_assets.db "SELECT COUNT(*) FROM artworks;"

如果本机没有安装 sqlite3 命令行工具，可以用 Python 验证：

python -c "import sqlite3; print(sqlite3.connect('art_assets.db').execute('select count(*) from artworks').fetchone())"

6.2 画师名带“画师:”前缀导致检索失败

现象：入库时artist字段存成画师:悟之心，查询--artist 悟之心返回空。

原因：等值查询artist = '悟之心'不会匹配画师:悟之心。

解决方案：入库前清理前缀。更稳妥的方式是数据导入时写一个预处理函数：

def normalize_artist(raw): raw = raw.strip() for prefix in ["画师:", "画家:", "作者:", "Artist:"]: if raw.startswith(prefix): raw = raw[len(prefix):].strip() break return raw

6.3 标签搜索不准

现象：用LIKE '%插画%'搜索，把风景插画、插画师都匹配出来了。

解决方案：使用逗号包裹后的精确匹配：

sql += " AND (',' || tags || ',') LIKE ?" params.append(f"%,{tag},%")

这种写法的前提是入库时tags严格使用英文逗号分隔，且没有空格前缀。

6.4 中文乱码或 CSV 被 Excel 打开乱码

现象：脚本输出的内容在终端正常，导出 CSV 后双击打开中文乱码。

原因：CSV 用了utf-8编码，但 Windows Excel 默认按 ANSI 打开。

解决方案：导出时使用utf-8-sig编码：

open(output, "w", newline="", encoding="utf-8-sig")

终端中文乱码则通常是因为 Windows 控制台默认编码不是 UTF-8，可以设置环境变量：

set PYTHONIOENCODING=utf-8

或者在 Python 脚本顶部加：

import sys sys.stdout.reconfigure(encoding="utf-8")

6.5 PID 撞号或重复导入报错

现象：从两个来源导入数据时，两个来源都从 100000 开始编号，导致主键冲突。

解决方案：明确主键策略。推荐把外部 PID 放入source_pid字段，本地主键使用自增id：

id INTEGER PRIMARY KEY AUTOINCREMENT source_pid TEXT source_name TEXT UNIQUE(source_name, source_pid)

这样既保留外部编号，又不会撞号。

6.6 查询慢的排查顺序

图片资产库如果达到十万级以上，查询变慢时按以下顺序排查：

1. 是否给artist、tags、file_hash建了索引。
2. 是否使用LIKE '%关键词%'导致索引失效。
3. 是否需要去掉tags字符串字段，改用标签关联表。
4. 是否考虑把 SQLite 迁移到 MySQL、PostgreSQL。

7. 从个人脚本到生产级图库的扩展方向

7.1 增加 Web 管理界面

命令行工具适合个人使用，不适合团队成员共同维护。扩展方向是加一个 Web 层，比如 Flask、FastAPI 或 Django，提供以下接口：

Web 层不直接操作图片文件，而是继续调用资产服务层，便于以后迁移到对象存储。

7.2 图片文件与数据库分离

个人示例中file_path指向本地磁盘。生产环境中，文件应该放入对象存储、私有文件服务器或者 CDN，数据库只保存对象的 key 或 URL。

按这个思路重构后，file_path字段更合适的名字是file_object_key：

file_path 存本地绝对路径 object_key 存 minio 或 OSS 的 key

查询时通过object_key拼接访问地址，而不是直接访问服务器文件系统。

7.3 画师别名与统一身份

作品量上来后，“悟之心”“悟心”“WuZhiXin”可能是同一个人，需要统一身份。

方案是把artworks.artist改成artist_id外键：

artworks.artist_id -> artists.artist_id artists.display_name = '悟之心' artists.aliases = '悟心,WuZhiXin'

查询时仍按展示名检索，但维护时只需改artists表，不需要批量更新作品表。

7.4 权限、审核与版权追踪

个人图库只有一个操作者，团队图库必须有完整权限模型。

建议引入三个表：

• 用户表：登录用户。
• 作品权限表：记录谁可以查看、编辑、删除某张作品。
• 操作日志表：记录每次增删改的用户、时间、操作内容。

版权追踪方面，source_url字段只能记录来源，不能证明授权范围。更完整的做法是增加license_type字段：

license_type TEXT -- ORIGINAL 原创 / AUTHORIZED 已授权 / PUBLIC 公开素材 license_file TEXT -- 授权书文件路径

7.5 自动化导入管道

如果每天都有新作品要归档，手动敲命令不现实。可以按以下链路做批量导入：

1. 扫描目录，提取文件路径、文件大小、哈希。
2. 通过文件名或现有元数据解析标题和画师。
3. 对哈希做去重检查。
4. 生成 PID，写入数据库。
5. 生成导入日志，失败记录单独存放。

批处理脚本与add命令共用同一个insert逻辑，避免两套代码行为不一致。

8. 落地建议与实用清单

8.1 个人图库落地建议

个人数字绘画资产库不需要一上来就做成微服务、上容器化，按下面顺序落地即可：

1. 先用 SQLite 保存数据，目录结构保持简单。
2. 入库时强制传 PID、标题、画师、文件路径四要素。
3. 对每张图片计算 SHA-256，并建立唯一约束。
4. 画师名一律归一化，不存“画师:”前缀。
5. 标签统一用英文逗号分隔，检索用',' || tags || ','。
6. 定期运行dup检查历史数据中的重复图片。
7. 每次导出 CSV 都使用utf-8-sig，避免 Excel 乱码。
8. 图片文件本身纳入备份，数据库文件也纳入备份。

8.2 数据导入前检查清单

导入一批新作品前，建议逐项确认：

8.3 新手最容易忽略的三件事

第一，文件名不是标识。不要依赖文件名做查重和溯源，文件哈希和 PID 才是可靠依据。

第二，字段可以少，但不能没有扩展位。file_hash、created_at、updated_at这三个字段在当前阶段看似增加工作量，但它决定了你后面能不能做去重、能不能回答“这张图什么时候入库的”。

第三，去重要在入口做，而不是定期做。如果每次导入前都检查哈希并把文件哈希字段建为唯一索引，历史数据就不会累积大量重复内容。

数字绘画资产管理本质上不是一个高深技术问题，而是一个“元数据建模”问题。只要把 PID、画师署名、文件哈希、标签和来源这几个维度设计清楚，个人维护一千张图和团队维护十万张图的差别，就只是存储方案、权限和自动化程度的不同。先把最小模型跑通，再根据实际痛点逐步扩展。