一个本地NMB数据阅读器无名氏No.68758003 只看PO
2026-06-01(一)18:07:05 ID:SLDLTVR 回应
最开始只是想给大洛山的串留个档，然后
下都下了，整个本地阅读器吧( ´∀`)
整都整了，做个服务器版吧，手机就也能看了( ﾟ∀ﾟ)
做都做了，把检索也加上吧( ﾟ 3ﾟ)
加都改加了，把整个流程改完整点吧(ゝ∀･)
现在觉得整这么麻烦为啥我不直接上岛看了(*ﾟーﾟ)
总之这是个从下载数据到双端阅读的NMB阅读器|-` )
无标题无名氏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
只是因为我在后端方面过于外行|д` )导致的名词和方案对不上
无标题无名氏No.68810156
2026-06-09(二)00:14:10 ID: gEGGVQn
post -- 存储所有post，包括串首，特别地，串首的page_num为0
thread_id, INT
id, INT
cookie, CHAR(7)
page_num, INT
is_po, BOOL
is_sage, BOOL
is_admin, BOOL
PRI(thread_id, id)
KEY(thread_id, page_num) -- 用于串内随机访问某页
KEY(thread_id, cookie) -- 用于串内查找某个cookie的发言
KEY(cookie, id) -- 用于查找某个cookie的所有发言
thread -- 存储所有串首
id, INT
cookie, CHAR(7)
is_sage, BOOL
is_admin, BOOL
installment, FLOAT -- 展示用的系列内写作顺序，可能有间章
PRI(id)
KEY(cookie) -- 用于查找某个cookie发的所有串
post_content
id, INT
thread_id, INT
cookie, CHAR(7)
content, VARCHAR(8192)
img, VARCHAR(128)
title, VARCHAR(64)
name, VARCHAR(64)
created_at, TIMESTAMP
PRI(id)
thread_content
id, INT
cookie, CHAR(7)
replies, INT
content, VARCHAR(8192)
img, VARCHAR(128)
title, VARCHAR(64)
name, VARCHAR(64)
created_at, TIMESTAMP
PRI(id)
tag_registry
tag_id, INT
tag_type, VARCHAR(64) -- 如“serie”、“status”
tag_name, VARCHAR(64) -- 如“大洛山系列”、“连载”
PRI(tag_id) AI
UNI(tag_type, tag_name)
thread_tag
thread_id, INT
tag_id, INT
PRI(id, tag_id)
KEY(tag_id, id)
无标题无名氏No.68810181
2026-06-09(二)00:17:27 ID: SLDLTVR (PO主)
>>No.68810159
(*ﾟ∇ﾟ)bbbbb
行，白天上工位看看GPT还有啥建议没，我感觉也没啥别的了
无标题无名氏No.68811494
2026-06-09(二)09:47:11 ID: SLDLTVR (PO主)
给了一堆建议但好多是咱昨天说过的
需要关注一下的就下面几个
1.content用TEXT
2.created_at存INT，UNIX时间戳
3.PRI(id, tag_id),KEY(tag_id, id)这两个应该PRI(thread_id, tag_id),KEY(tag_id, thread_id)
4.installment用NUMERIC这种精确的格式
5.类型、系列那堆加回thread，要不还得验证tag里这些东西是否唯一
无标题无名氏No.68811701
2026-06-09(二)10:30:13 ID: gEGGVQn
>>No.68811494
1的理由是什么，text是当前位置存一个指针指向真正的内容，会引发大量随机IO，我认为VARCHAR更好
2的话那就用INT吧，TIMESTAMP确实容易引发一些问题
3是我改列名的时候忘记改了
4我忘了这回事了，改NUMERIC（或者是DECIMAL）确实更好
5的话，首先从应用层我们就该保证一个thread_id只有一个tag_type为serie的tag_id，其次要做的更好的话那就thread_tag结构改成thtead_id, tag_id, tag_type，然后UNI(thread_id, tag_type)，具体地，UNIQUE KEY (thread_id, (IF(tag_type = 'CUSTOM_TAG', NULL, tag_type)))，tag_registry表结构不变
但是这样的话tag_type冗余存储了一遍，空间不是问题，tag估计最多也就十万级，主要是这样写起来有点丑( ﾟ∀。)不过这样的设计我觉得挺合理的