模仿陌陌八張頭像的資料庫，應該如何建表才合適？

我想大家都已經看過我以前的問題了。就是吐槽創業好難。自己能力不足，基本上我獲得的經驗都是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張圖片都是從一張圖片裁剪來額話，原圖可以上傳到七牛這樣的雲端儲存，定義好要取的圖片樣式，使用它的圖片處理取就行了。資料庫只存原圖的資訊，圖片樣式可以寫在設定檔中。

說一個另類的解決方案，用七牛的雲端儲存體服務，取圖片的時候帶上需要的尺寸會自動轉換

沒清楚問題是什麼。八張頭像為啥要存在資料庫裡面？

