无标题无名氏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.68809621

2026-06-08(一)23:00:00 ID: gEGGVQn

>>No.68809512
每条是24字节，十四万条数据是3MB左右，对内存来说这不算事，对传输来说也在几十毫秒左右，然后你可以在python里很简单地进行切片之类的操作，然后mysql我也不用写并发锁，还是第一种好我觉得

无标题无名氏No.68809713

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

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

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

无标题无名氏No.68809725

2026-06-08(一)23:13:47 ID: gEGGVQn

>>No.68809620
genre和status和series，和tag具体区别是什么？如果区别不大的话，整理进tags能复用同一套反向索引逻辑

无标题无名氏No.68809740

2026-06-08(一)23:15:34 ID: gEGGVQn

>>No.68809713
首先下载是多线程的，其次永远不要相信你的用户( ﾟ∀。)

无标题无名氏No.68809761

2026-06-08(一)23:17:27 ID: gEGGVQn

>>No.68809620
installment重复倒是不会添加多少代码工作量，也就加个第二关键字的事，但是为什么会出现重复的场景( ﾟ∀。)

无标题无名氏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.68809887

2026-06-08(一)23:34:36 ID: gEGGVQn

>>No.68809850
不要紧啊，thread表能有多少数据，我估算的时候算的是把整个岛爬完，这个情况下post表会是千万左右，thread会是十万左右，不差这点，content多少个零后面的零头算不上( ﾟ∀。)

无标题无名氏No.68809904

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

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