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

我想大家都已经看过我以前的问题了。就是吐槽创业好难。自己能力不足，基本上我获得的经验都是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张图片都是从一张图片裁剪来额话，原图可以上传到七牛这样的云存储，定义好要取的图片样式，使用它的图片处理取就行了。数据库只存原图的信息，图片样式可以写在配置文件中。

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

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