写作绅士,读作丧尸 X岛揭示板
顺猴者昌 逆猴者亡 首页版规 |用户系统 |移动客户端下载 | 丧尸路标 | | 常用图串及路标 | 请关注 官方公众号:【X岛揭示板】 官方微博: 【@X岛极速版】| 人,是会思考的芦苇
常用串:·豆知识·跑团板聊天室·公告汇总串·X岛路标

No.68758003 - 一个本地NMB数据阅读器 - 技术宅


回应模式
No.68758003
名 称
E-mail
标题
颜文字
正文
附加图片
•程序语言、压制投稿、视频制作以及各计算机领域的技术问题
•我觉得还是CSDN靠谱一点
•本版发文间隔为15秒。

一个本地NMB数据阅读器 无名氏 2026-06-01(一)18:07:05 ID:SLDLTVR [举报] [订阅] [只看PO] No.68758003 [回应] 管理
最开始只是想给大洛山的串留个档,然后

下都下了,整个本地阅读器吧( ´∀`)
整都整了,做个服务器版吧,手机就也能看了( ゚∀゚)
做都做了,把检索也加上吧( ゚ 3゚)
加都改加了,把整个流程改完整点吧(ゝ∀・)

现在觉得整这么麻烦为啥我不直接上岛看了(*゚ー゚)

总之这是个从下载数据到双端阅读的NMB阅读器|-` )
无标题 无名氏 2026-06-08(一)22:17:25 ID:SLDLTVR (PO主) [举报] No.68809321 管理
>>No.68809258
都保留着我觉得没问题,然后我想再加个统计是该串的第几个回复,用来算调整显示数量后的页数。就纯是我个人习惯,想一页显示多一点( ´∀`)
之后默认按页数显示,提供个调整的选项就好了
无标题 无名氏 2026-06-08(一)22:22:19 ID:SLDLTVR (PO主) [举报] No.68809359 管理
然后我觉得还是要保留主串分类、追加tag、系列名、系列编号的项目
我最初的设想是做成更接近文库的东西
所以想保留这些作为检索或者分类的依据
这些该单做个表还是整合到thread/threadpost里
无标题 无名氏 2026-06-08(一)22:33:56 ID:gEGGVQn [举报] No.68809431 管理
>>No.68809321
两种方案
一种是python通过sql请求这个串下的所有回复的元数据然后存在内存,然后因为他只有元数据,占的内存可以接受,然后在python里面怎么处理都行,缓存生命有多长可以作为一个配置项
一种是数据表加一个列,表示这是串底下的第几个回复,这样的话就需要每次写入新回复都要先读取最后一条回复,对并发写入不太友好(不过并发写入应该是比较小的需求吧)
直接offset太丑了,第二种我也觉得有点丑,我是倾向于第一种
无标题 无名氏 2026-06-08(一)22:38:39 ID:gEGGVQn [举报] No.68809462 管理
>>No.68809359
整理进thread表吧,毕竟thread表的职责就是用来显示串首列表的
无标题 无名氏 2026-06-08(一)22:44:48 ID:SLDLTVR (PO主) [举报] No.68809512 管理
>>No.68809431
这个我是倾向用第二种
一次下14w条元数据下来也需要点时间了
无标题 无名氏 2026-06-08(一)22:59:43 ID:SLDLTVR (PO主) [举报] No.68809620 管理
那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的所有串

那个关联表只是我搜到的推荐方式,我也不确定是否合适(つд⊂)
无标题 无名氏 2026-06-08(一)23:00:00 ID:gEGGVQn [举报] No.68809621 管理
>>No.68809512
每条是24字节,十四万条数据是3MB左右,对内存来说这不算事,对传输来说也在几十毫秒左右,然后你可以在python里很简单地进行切片之类的操作,然后mysql我也不用写并发锁,还是第一种好我觉得
无标题 无名氏 2026-06-08(一)23:12:45 ID:SLDLTVR (PO主) [举报] No.68809713 管理
>>No.68809621
( ゚∀゚)bbbb那就按第一种来

不过应该也不会有并发写入吧,最终有权限写数据应该只有那一个下载线程吧
无标题 无名氏 2026-06-08(一)23:13:47 ID:gEGGVQn [举报] No.68809725 管理
>>No.68809620
genre和status和series,和tag具体区别是什么?如果区别不大的话,整理进tags能复用同一套反向索引逻辑
无标题 无名氏 2026-06-08(一)23:15:34 ID:gEGGVQn [举报] No.68809740 管理
>>No.68809713
首先下载是多线程的,其次永远不要相信你的用户( ゚∀。)
无标题 无名氏 2026-06-08(一)23:17:27 ID:gEGGVQn [举报] No.68809761 管理
>>No.68809620
installment重复倒是不会添加多少代码工作量,也就加个第二关键字的事,但是为什么会出现重复的场景( ゚∀。)
收起 查看大图 向左旋转 向右旋转
无标题 无名氏 2026-06-08(一)23:30:41 ID:SLDLTVR (PO主) [举报] No.68809850 管理
>>No.68809725
如果都写进tag也能分情况检索的话,都放tags里也行。比如图里这样的按类型、系列、状态分别检索。tags里再有写其他的关键词,比如某个串的别名。

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

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

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

就为了这个一个把int改成float多占点空间感觉也没必要
无标题 无名氏 2026-06-08(一)23:34:36 ID:gEGGVQn [举报] No.68809887 管理
>>No.68809850
不要紧啊,thread表能有多少数据,我估算的时候算的是把整个岛爬完,这个情况下post表会是千万左右,thread会是十万左右,不差这点,content多少个零后面的零头算不上( ゚∀。)
无标题 无名氏 2026-06-08(一)23:36:56 ID:SLDLTVR (PO主) [举报] No.68809904 管理
>>No.68809887
那就改成支持小数的格式吧(つд⊂)省的再出现什么意想不到的情况
无标题 无名氏 2026-06-08(一)23:36:58 ID:gEGGVQn [举报] No.68809905 管理
>>No.68809850
那这样的话就改FLOAT就好了,因为这样考虑的话有时候可能有不少类似“间章”的串
无标题 无名氏 2026-06-08(一)23:39:32 ID:gEGGVQn [举报] No.68809927 管理
说起来,你的“系列”可以做成
自定义
现有系列
这样的结构,然后用js在用户选择自定义的时候再在下面出现一个输入框,选择其他选项的时候输入框消失,这样美观一点
无标题 无名氏 2026-06-08(一)23:42:21 ID:SLDLTVR (PO主) [举报] No.68809947 管理
>>No.68809927
确实这样会好很多,主要是一开始AI给大致样式写完之后我也没细改。⊂彡☆))∀`)懒比一个
无标题 无名氏 2026-06-08(一)23:42:25 ID:gEGGVQn [举报] No.68809948 管理
>>No.68809850
但是比较麻烦的一点就是怎么处理“系列”和“分类”,直接做成tag的话你比较难这么方便的显示,分离出来的话代码逻辑我还得想想( ゚∀。)
无标题 无名氏 2026-06-08(一)23:54:15 ID:SLDLTVR (PO主) [举报] No.68810016 管理
>>No.68809927
如果所有thread都下载下来不占资源的话,全归到tags里,然后固定位置放固定内容行不。

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

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

UP主: