无标题无名氏No.68809512

2026-06-08(一)22:44:48 ID: SLDLTVR (PO主)

>>No.68809431
这个我是倾向用第二种
一次下14w条元数据下来也需要点时间了

无标题无名氏No.68809620

2026-06-08(一)22:59:43 ID: SLDLTVR (PO主)

那thread的结构就像这样行吗

thread
（存储所有串首）
id, INT
cookie, CHAR(7)
is_sage, BOOL
is_admin, BOOL
genre, VARCHAR(64) -- 串类型分类，跑团、故事、欢乐恶搞之类的
tags, 关联表 -- 标签，会有多个，可自定义
series, VARCHAR(64) -- 系列名称
status, VARCHAR(64) -- 状态，连载中、完结、痛之类的
installment, INT -- 纯展示用的系列内写作顺序，可能重复
PRI(id)
KEY(cookie) -- 用于查找某个cookie的所有串

那个关联表只是我搜到的推荐方式，我也不确定是否合适(つд⊂)

无标题无名氏No.68809713

2026-06-08(一)23:12:45 ID: SLDLTVR (PO主)

>>No.68809621
( ﾟ∀ﾟ)bbbb那就按第一种来

不过应该也不会有并发写入吧，最终有权限写数据应该只有那一个下载线程吧

无标题无名氏No.68809850

2026-06-08(一)23:30:41 ID: SLDLTVR (PO主)

>>No.68809725
如果都写进tag也能分情况检索的话，都放tags里也行。比如图里这样的按类型、系列、状态分别检索。tags里再有写其他的关键词，比如某个串的别名。

>>No.68809740
确实( ﾟ∀。)

>>No.68809620
这个我最开始也没想到。

还是dmg的团，有个凶宅试住员是第13部。中间给主角跑没结团了。然后dmg另开了个串，是给主角复活的团。然后这个团的编号就，要么13.5要么13（主要我最开始也没想起来这个，就顺着往后排其他的了|д` )）

就为了这个一个把int改成float多占点空间感觉也没必要

无标题无名氏No.68809904

2026-06-08(一)23:36:56 ID: SLDLTVR (PO主)

>>No.68809887
那就改成支持小数的格式吧(つд⊂)省的再出现什么意想不到的情况

无标题无名氏No.68809947

2026-06-08(一)23:42:21 ID: SLDLTVR (PO主)

>>No.68809927
确实这样会好很多，主要是一开始AI给大致样式写完之后我也没细改。⊂彡☆))∀`)懒比一个

无标题无名氏No.68810016

2026-06-08(一)23:54:15 ID: SLDLTVR (PO主)

>>No.68809927
如果所有thread都下载下来不占资源的话，全归到tags里，然后固定位置放固定内容行不。

比如tags第一个默认genre，第二个series，第三个installment，第四个status，后面的都当成普通tag。没有的时候对应位置填个占位符。我不知道sql能不能[None,None]这种

访问的时候把所有thread都下载完之后本地拆一遍这样

无标题无名氏No.68810050

2026-06-09(二)00:00:03 ID: SLDLTVR (PO主)

>>No.68810038
( ﾟ∀。)没有没有，是顺手写进去了

>>No.68810022
( ´∀`)bbbb

无标题无名氏No.68810067

2026-06-09(二)00:01:42 ID: SLDLTVR (PO主)

>>No.68810047
只是因为我在后端方面过于外行|д` )导致的名词和方案对不上