V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
GeekHub
RihcardLu
V2EX  ›  程序员

两种管理图片的方式,哪个更好?

  •  1
     
  •   RihcardLu · 2016-09-14 02:19:16 +08:00 · 2874 次点击
    这是一个创建于 1477 天前的主题,其中的信息可能已经有所发展或是发生改变。

    1. 单独管理图片

    图片单独建表管理,通过图片类型结合关联 id 查找图片

    优点:

    1. 图片统一管理
    2. 插入多张图片比较方便
    3. 方便拓展,如果有某个类型需要新加图片,不用去原表示上新加字段

    缺点:

    1. 存取、删除图片不不便
    2. 如果同一个 id 的商品有多张不同类型的图片,需要通过 type 出字段来区分,从理解的一致性上来看可能存在偏差

    2. 直接将图片设为相关表的一个字段

    建立图片相关字段,将图片所有有关信息以字符串的形式全部存入

    优点:

    1. 图片随相关表管理,逻辑上不用再绕一个弯
    2. 图片存取、删除方便

    缺点:

    1. 拓展麻烦,如果图片过多,可能造成溢出字段溢出
    2. 图片查找,基本上不可能(当然有可能根本不会有图片查找需求,这也是从宽拓展角度考虑的)
    3. 不能分辨同一个类型的不同位置的图片

    ps:有句话说得好,过早的优化是万恶之源,可能考虑了这么多拓展性的内容,最后都用不上

    若问题有描述不清楚的地方,请随时指出;如果大家有更好的意见或建议,望不吝赐教。

    谢谢!

    14 条回复    2016-09-14 10:56:27 +08:00
    zpvip
        1
    zpvip   2016-09-14 06:26:55 +08:00
    imn1
        2
    imn1   2016-09-14 07:13:45 +08:00
    我是建议文件名和 hash(不一定非要 md5)有某种相关,将来总有用
    ersic
        3
    ersic   2016-09-14 09:11:59 +08:00
    一楼发的链接里面的
    RihcardLu
        4
    RihcardLu   2016-09-14 09:14:49 +08:00 via Android
    @zpvip 这里面写的貌似和第一种差不多
    @imn1 你是说图片文件名和它的 md5 (假设为 md5 ),这个怎么关联?以后可能的应用场景有?
    qiayue
        5
    qiayue   2016-09-14 09:17:42 +08:00
    @RihcardLu 有一种需求,文章表只需要记录图片 ID ,使用的时候,直接通过图片 ID 通过自己的某种算法算出文件名和文件保存路径,就可以直接显示图片了,省去了再去查询图片表这一步。
    RihcardLu
        6
    RihcardLu   2016-09-14 09:34:40 +08:00 via Android
    @qiayue 第二种方法和你说的这种感觉差不多,文章表里直接存入图片信息,那么当一篇文章有多张图处于不同位置的图片,也是不太好处理的。
    qiayue
        7
    qiayue   2016-09-14 09:42:55 +08:00
    @RihcardLu 刚才举例用错了词,不应该说文章表,反正就是任意其他的表,里边有图片字段,只需要记录图片 ID 或者图片 hash ,最终使用就可以省去查询图片表这一步。

    至于文章正文中的图片,一般都直接存储图片的路径(相对或绝对),不会存图片 ID 。整个正文内容要么存成 markdown 格式,要么 html 格式,要么自定义格式。
    imn1
        8
    imn1   2016-09-14 09:57:12 +08:00
    @RihcardLu
    你想想 gavatar ,去哪头像都一样,应该明白我的意思吧

    我不清楚你要管理的这些图片来源,如果只是 CMS ,那未必有用,因为图片重复可能性不大
    但如果是不定多数用户上传,电商或者图站,海量图片存储,重复的概率不低
    用 hash 可以减少文件数量、存储空间,某种程度还可以减少带宽
    不过这种方式要花心思在路径上,因为可能多个 URL 指向同一个文件,如何做到 cdn 优化我就不清楚了

    或者现在你不能确定这种方式有用,但这是经验之谈,我玩集图多年,约 30T 图片就是这样管理的,网站上一样有用
    文件名带有 hash ,搜索、移动、清理就不用再一次 hash
    尤其是清理的时候很方便,避免误杀
    winglight2016
        9
    winglight2016   2016-09-14 10:04:02 +08:00
    像这种文件资源,一般不需要放在业务数据库里,业务库里只保留图片 url 就好,图片服务单独建一个独立系统方便以后扩展升级
    RihcardLu
        10
    RihcardLu   2016-09-14 10:08:32 +08:00
    @qiayue 关于文章存储图片的我举的例子也不恰当。

    你说的记录图片 id 或图片的 hash ,适应的场景可能只是单张图片,如头像这种,理解有误吗?

    @imn1 确实没有遇到过海量图片存储这种方式,不过现在知道了老司机的经验,学到了,十分感谢啊!
    RihcardLu
        11
    RihcardLu   2016-09-14 10:11:25 +08:00
    @winglight2016 你说的很有道理,不过由于初期环境限制,系统设计做不到那么尽善尽美。而且我上面主要想讨论的也是怎么存储图片 id 的问题,尤其是涉及到多图片的时候。
    ecloud
        12
    ecloud   2016-09-14 10:28:38 +08:00
    直接存 url ,将来图片服务器可以考虑换成 CMS ,有了 CMS 你的所有扩展需求问题都解决了。
    isCyan
        13
    isCyan   2016-09-14 10:40:40 +08:00
    为什么要把图片和商品死死连在一起…… 我支持你的第一种。而且不懂为什么同一个 id 的商品有多张不同类型的图片

    表一,图片,图片 ID ,图片地址,图片描述
    表二,商品,商品名称,商品价格
    表三,文章,文章标题,文章内容
    表四,图片关系,对象类型(可以是文章或者商品),图片 ID ,对象 ID (如果是文章就是文章 ID ,是商品就是商品 ID )

    存取、删除图片没什么麻烦的啊。

    本人学识短浅,上述仅供参考
    winglight2016
        14
    winglight2016   2016-09-14 10:56:27 +08:00
    @RihcardLu 你的问题我觉得不是尽善尽美,而是使用 id 去关联图片是一个常见的坑。如果商品有多张图片,可以采用 url1,url2,url3...这种方式就可以保存了。如果你对文件服务没多少概念,那也可以直接使用七牛这样的云服务,反正 10g 以内都免费
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2133 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 113ms · UTC 15:10 · PVG 23:10 · LAX 08:10 · JFK 11:10
    ♥ Do have faith in what you're doing.