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