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

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

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

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

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

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

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

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

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

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

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

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

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

>>No.68810022
( ´∀`)bbbb

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

>>No.68810084
对

>>No.68810159
(*ﾟ∇ﾟ)bbbbb
行，白天上工位看看GPT还有啥建议没，我感觉也没啥别的了

给了一堆建议但好多是咱昨天说过的

需要关注一下的就下面几个
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里这些东西是否唯一

要不你直接问AI吧，你们俩的细节解释的我都不太懂(;´ヮ`)7
后端我真不会啊(つд⊂)

不过我是觉得你直接定就好了(　ﾟ 3ﾟ)

>>No.68811867
别的没了，对TEXT这块AI原文是


TEXT 不会因为类型叫 TEXT，就天然变成“大量随机 IO”。真正决定 IO 的是：

你怎么查
一次查多少行
数据库怎么存储长字段
这些正文是不是被频繁读
先说结论

如果你的页面是“先按索引找一页 post_no，再把这一页对应的 content 读出来”，TEXT 完全正常
真正容易带来 IO 压力的，不是 TEXT 这个类型本身，而是“正文很大、读得很频繁、而且每次查很多不需要的正文”
你的场景里要点是

目录页不要扫正文
目录页只查 thread / tag / status / installment / count 这些轻字段，不碰 content，IO 就很轻。

阅读页按页取少量帖子正文
比如一次只取 20/50 条，这也没问题。
你本来就是要把正文显示出来，这部分 IO 无论 VARCHAR(8192) 还是 TEXT 都躲不掉。

不要在大范围筛选里直接扫 content
如果你以后做全文搜索，别用普通 LIKE '%xxx%' 去硬扫大表。
那才是真的 IO 杀手。要么上全文索引，要么单独做搜索方案。

为什么 VARCHAR(8192) 也不能避免这个问题
就算你把列定义成 VARCHAR(8192)：

里面存的还是长正文
读正文时照样要把正文拿出来
所以 IO 压力本质没变
也就是说：

TEXT 不是问题来源
“频繁扫描大正文”才是问题来源
如果你担心 IO，可以这样设计

post 表只放轻字段和定位字段
post_content 单独放 content
列表、筛选、分页尽量先走轻表
只有真正打开阅读页时，才按当前页 post_id 去取正文
其实你现在这个“索引表 + 正文表”思路，本身就是在避免不必要的正文 IO，这个方向是对的。

一句话
TEXT 不会天然导致大量随机 IO；
真正导致大量 IO 的，是把正文当索引字段去大范围扫描。
你这种阅读器场景，只要“目录查轻字段、阅读页按页取正文”，TEXT 是合适的。

>>No.68811867
你看着定一下就行了，我信你的(ゝ∀･)

>>No.68812311
是要从写数据库开始就屏蔽某些cookie吗
感觉在前端留给用户自己填屏蔽的饼就行

然后冗余的字段如果只是没必要而不是有负面影响的话，我觉得就先保留。删掉某一字段应该比之后想追加的时候，重新加数据容易吧(　ﾟ 3ﾟ)

>>No.68812678
( ﾟ∀ﾟ)bbbb

>>No.68812678
结构没啥了，不过这个图片地址存一下原本的图床链接如何

我现在程序里下载的时候是把图片名改成串号的，默认串号全局唯一的情况下，图片地址只要确定哪个串需要图片就能知道

保存原图床链接是想着，万一下载的时候retry次数都用完了也没下下来图片，之后有人再用的时候可以再试着访问一次

>>No.68812767
( ﾟ∀。)确实哦，我这服务器带宽十分有限。不过访问量也没多少应该没事

给别人本地部署用的话，优先检查本地是否有图片肯定是对的。我现在就是存的图片url，但是优先读取本地图片。我的下载程序也会检查一遍已经过去的页面图片和内容缺不缺这个倒是考虑到了(ゝ∀･)

至于图床链接变不变的|д` )这个似乎没辙，所以还是下载到本地最稳妥

真到了本地没存，图床链接也换了，那就到时候再重新请求一下这个页面的数据更新一下链接吧，正好有page_num

>>No.68812750
我还在整理几份报告(つд⊂)
等几天整理完报告之后，我总结一下我这现有的功能和之后的需求啥的。数据库就按上面的来( ﾟ∀ﾟ)bbbb我再整理主要是前端部分的操作逻辑