当前位置:Gxlcms > PHP教程 > 模仿陌陌八张头像的数据库,应该如何建表才合适?

模仿陌陌八张头像的数据库,应该如何建表才合适?

时间:2021-07-01 10:21:17 帮助过:51人阅读

我想大家都已经看过我以前的问题了。就是吐槽创业好难。自己能力不足,基本上我获得的经验都是segmentfault上面一个个提问得来的。在这里,我要感谢哪些帮助过我的人,不管是多么幼稚的问题都会有人热心的回答你。
当然,我又有了新问题。就是陌陌的八张头像,陌陌在后台是如何保存的(就是如何建表的)
我的技术见解非常肤浅,但是我估计陌陌个人资料根本就不是用mysql来保存的,而用的是mongodb。

当然,图片文件肯定是存在文件系统里面的,路径肯定是保存在表里面的嘛!!
而要用mysql保存的话:

CREATE TABLE  travel_user_avatar(
  userId     INT UNSIGNED  PRIMARY KEY  NOT NULL  COMMENT ' 用户的唯一id',
  avatar0  VARCHAR(255) DEFAULT '',
  avatar1  VARCHAR(255)DEFAULT '',
  avatar2  VARCHAR(255)DEFAULT '',
  avatar3  VARCHAR(255)DEFAULT '',
   CONSTRAINT `useravatar` FOREIGN KEY (`userId`) REFERENCES `travel_user_meta` (`userId`) ON DELETE CASCADE ON UPDATE CASCADE
);

如果使用mysql,这样建表对吗?
最近做了一段时间的项目,还是发现了好多关系型数据库的不足。比如这个个人资料这一块,用非关系型数据库就要比关系型数据库要好很多啊!!

回复内容:

我想大家都已经看过我以前的问题了。就是吐槽创业好难。自己能力不足,基本上我获得的经验都是segmentfault上面一个个提问得来的。在这里,我要感谢哪些帮助过我的人,不管是多么幼稚的问题都会有人热心的回答你。
当然,我又有了新问题。就是陌陌的八张头像,陌陌在后台是如何保存的(就是如何建表的)
我的技术见解非常肤浅,但是我估计陌陌个人资料根本就不是用mysql来保存的,而用的是mongodb。

当然,图片文件肯定是存在文件系统里面的,路径肯定是保存在表里面的嘛!!
而要用mysql保存的话:

CREATE TABLE  travel_user_avatar(
  userId     INT UNSIGNED  PRIMARY KEY  NOT NULL  COMMENT ' 用户的唯一id',
  avatar0  VARCHAR(255) DEFAULT '',
  avatar1  VARCHAR(255)DEFAULT '',
  avatar2  VARCHAR(255)DEFAULT '',
  avatar3  VARCHAR(255)DEFAULT '',
   CONSTRAINT `useravatar` FOREIGN KEY (`userId`) REFERENCES `travel_user_meta` (`userId`) ON DELETE CASCADE ON UPDATE CASCADE
);

如果使用mysql,这样建表对吗?
最近做了一段时间的项目,还是发现了好多关系型数据库的不足。比如这个个人资料这一块,用非关系型数据库就要比关系型数据库要好很多啊!!

我觉得你的这个头像的地址都不一定需要储存,比如所有的用户头像都在一个文件夹下面,使用uid加另外一个标志区分一下文件名就好了,每次自动拼接一下url 。比如说/avatar_1000(uid)_a1(尺寸标志).jpg,/avatar_1000(uid)_a2.jpg 就好了~

这种情况也不是一定要mongodb的吧。。。直接分一个user_avatar表出来,id,user_id和avatar字段就好了。。个人是偏向于大量使用mysql..只有在特定(tag、关系)之类的地方用redis..mongodb几乎不用..

(本人才疏学浅,见笑)

先来说说可能的方式:

  1. 可以按照你给的方式
  2. 可以把列拆分成行 userId avatar index
  3. 可以存储Json格式 userId content -> 1,{avatars:["aaa.png","bbb.png"]}
  4. 或者用mongodb这些文档型的
  5. 把8图合并成一张存储,在客户端拆分。这样可以减少对服务器的请求次数。因为更改头像的业务比拉取头像图片远远要少得多。

现在回答你的问题:如何建表才合适?

如果产品的功能是不会再变了(8图头像),则第二条是不合适的;
接着如果用户的个人资料是包含头像一起的(每次查询个人资料的结果都会包含头像),则第四条是不合适的,因为涉及到跨越不同的数据库类型,而查询个人资料往往在社交软件中是一个频繁的操作。
如果数据库设计中avatar要和别的表关联,那么第三条是非常蛋疼的。

下面是另一种情形:
如果头像不一定由8图组成,可能是4图,可能是9图,那么按照第一条的设计方式是不行的
如果在线用户非常多,拉取头像图片非常频繁,那么第5条相比其他方式的运营成本要少


也就是说 设计可能会存在完美的设计,但是并不一定适合你当时的需求。你可能只有1000人的在线数,但是你搞分库分表读写分离,这不是蛋疼吗。
请不要过度设计!

也就是说 我以上说的都是废话。。。因为我没有回答你的问题····
你还是得按照你对业务本身的理解和对数据的预期,来选择最符合你的模式

解决方案太多了。

1、使用关系型数据库

由于用户和头像是一对多的关系,常见的做法就是建立两张表来描述这个关系就好了。

2、在图片的文件名上做文章

在图片的文件名上用特定的关键字来标识不同的图片,要用哪张就自己拼接哪张图片的URL就好了。

方法很多:
拼接URL,八张图各个命名放在不同文件名内。不存数据库,根据会员ID或是会员名来生成文件夹保存并存图像。
在图像字段使用 格式化后的数据统一存在一个字段里。如json。

如果8张图片都是从一张图片裁剪来额话,原图可以上传到七牛这样的云存储,定义好要取的图片样式,使用它的图片处理取就行了。数据库只存原图的信息,图片样式可以写在配置文件中。

说一个另类的解决方案,用七牛的云存储服务,取图片的时候带上需要的尺寸会自动转换

没清楚问题是什么。八张头像为啥要存在数据库里面?

人气教程排行