一部漫画有200多个章节，一个章节里面有200多张图片，图片是否分表储存？

图片以文件方式储存,数据库存的是路径,单独一个表方便管理

分开存好，因为你不需要一次返回，懒加载

• 1.图片单独存储主要方便在很多地方都会使用到这张图片，这样根据id关联查询即可。一次修改，N个地方都修改了。
• 2.单表存储肯定是查询最快的。个人觉得你这个多次调用的估计不会有，最好还是单表存储。就算有，也单表存储空间换时间。你这个漫画肯定不止一本

图片一般都云存储oss

图片单独一个表储存有什么好处？

答案是： 没有啥好与不好、对与不对，关键看能否满足当下需求、是否更好的满足未来需求的变化。

如果你把文件分单独表存储了、comic 主表中 chapter 里面 json 储存图片文件表的唯一标记，图片文件表记录漫画、章节、oss的类型、存储oss 上的path以及点击量、类型、图片大小、上传人等等字段，会为你后期的业务发展提供便利的。 另外：文件分单独表存储了还可以缩小漫画主表的大小，数据表大小越小，后面迁移的时候会更方便哦。

单独一个表储存在查询的时候会单独查询一次图片表 岂不是会慢很多?

答：这个问题基本不存在，像这种数据肯定会做一层缓存，详情页查询数据的时候可以用懒加载，图片存七牛或阿里云Oss ，如果是列表页，基本也不会展示很多详情内容，列表顶多是展示缩略图。

我们写出的程序质量的高低取决于业务数据表结构设计的设计的合理性。 但设计时从哪些方面考虑呢？这时就需要我们好好考虑了。 个人认为需要考虑：

• 业务数据是如何展示的；
• 业务数据的发展量；
• 业务需求的变化情况

具体到你说的漫画程序设计上来说的话：

1. 漫画程序需求包括但不局限于：按照列表展示，查看详情，对漫画的欢迎程度、点击量等排序等、漫画数据的展示修改权限控制、漫画数据的缓存与更新等等业务；
2. 业务的数据量的增长量的考虑，测试数据填充与并发测试；
3. 考虑清楚根据业务的发展，对业务的逻辑进行变更。例如：以前的漫画所有数据都是按照单表进行存储的，后面有一个需求，需要你把某一类型漫画数据按照包打包进行下载。那你修改起来的代价就比较大了。

所以：建议你分表，而且好好思考设计好的表的利弊

图片放在 oss 上 再加上cdn处理，速度飞快，除非你的漫画是 韩漫 那就帮不了你啦！

啥动漫？

图片储存在oss，数据库通过json储存数据，太大可以分