图片单独建表管理,通过图片类型结合关联 id 查找图片
优点:
缺点:
建立图片相关字段,将图片所有有关信息以字符串的形式全部存入
优点:
缺点:
ps:有句话说得好,过早的优化是万恶之源,可能考虑了这么多拓展性的内容,最后都用不上
若问题有描述不清楚的地方,请随时指出;如果大家有更好的意见或建议,望不吝赐教。
谢谢!
1
zpvip 2016-09-14 06:26:55 +08:00
|
2
imn1 2016-09-14 07:13:45 +08:00
我是建议文件名和 hash(不一定非要 md5)有某种相关,将来总有用
|
3
ersic 2016-09-14 09:11:59 +08:00
一楼发的链接里面的
|
4
RihcardLu OP |
5
qiayue 2016-09-14 09:17:42 +08:00
@RihcardLu 有一种需求,文章表只需要记录图片 ID ,使用的时候,直接通过图片 ID 通过自己的某种算法算出文件名和文件保存路径,就可以直接显示图片了,省去了再去查询图片表这一步。
|
6
RihcardLu OP @qiayue 第二种方法和你说的这种感觉差不多,文章表里直接存入图片信息,那么当一篇文章有多张图处于不同位置的图片,也是不太好处理的。
|
7
qiayue 2016-09-14 09:42:55 +08:00
@RihcardLu 刚才举例用错了词,不应该说文章表,反正就是任意其他的表,里边有图片字段,只需要记录图片 ID 或者图片 hash ,最终使用就可以省去查询图片表这一步。
至于文章正文中的图片,一般都直接存储图片的路径(相对或绝对),不会存图片 ID 。整个正文内容要么存成 markdown 格式,要么 html 格式,要么自定义格式。 |
8
imn1 2016-09-14 09:57:12 +08:00
@RihcardLu
你想想 gavatar ,去哪头像都一样,应该明白我的意思吧 我不清楚你要管理的这些图片来源,如果只是 CMS ,那未必有用,因为图片重复可能性不大 但如果是不定多数用户上传,电商或者图站,海量图片存储,重复的概率不低 用 hash 可以减少文件数量、存储空间,某种程度还可以减少带宽 不过这种方式要花心思在路径上,因为可能多个 URL 指向同一个文件,如何做到 cdn 优化我就不清楚了 或者现在你不能确定这种方式有用,但这是经验之谈,我玩集图多年,约 30T 图片就是这样管理的,网站上一样有用 文件名带有 hash ,搜索、移动、清理就不用再一次 hash 尤其是清理的时候很方便,避免误杀 |
9
winglight2016 2016-09-14 10:04:02 +08:00
像这种文件资源,一般不需要放在业务数据库里,业务库里只保留图片 url 就好,图片服务单独建一个独立系统方便以后扩展升级
|
10
RihcardLu OP |
11
RihcardLu OP @winglight2016 你说的很有道理,不过由于初期环境限制,系统设计做不到那么尽善尽美。而且我上面主要想讨论的也是怎么存储图片 id 的问题,尤其是涉及到多图片的时候。
|
12
ecloud 2016-09-14 10:28:38 +08:00
直接存 url ,将来图片服务器可以考虑换成 CMS ,有了 CMS 你的所有扩展需求问题都解决了。
|
13
isCyan 2016-09-14 10:40:40 +08:00
为什么要把图片和商品死死连在一起…… 我支持你的第一种。而且不懂为什么同一个 id 的商品有多张不同类型的图片
表一,图片,图片 ID ,图片地址,图片描述 表二,商品,商品名称,商品价格 表三,文章,文章标题,文章内容 表四,图片关系,对象类型(可以是文章或者商品),图片 ID ,对象 ID (如果是文章就是文章 ID ,是商品就是商品 ID ) 存取、删除图片没什么麻烦的啊。 本人学识短浅,上述仅供参考 |
14
winglight2016 2016-09-14 10:56:27 +08:00
@RihcardLu 你的问题我觉得不是尽善尽美,而是使用 id 去关联图片是一个常见的坑。如果商品有多张图片,可以采用 url1,url2,url3...这种方式就可以保存了。如果你对文件服务没多少概念,那也可以直接使用七牛这样的云服务,反正 10g 以内都免费
|