作者:
wix3000 (癢，好吃)
2017-11-19 21:10:39嗯... 雖然感覺用noSQL可以很輕鬆解決
不過暫時還是只有MySQL可以用
想請問一下，假設做一款網路手遊
每個玩家都會有很多的資料，比如說擁有的卡片、編隊、某某任務的進度，道具數量等等
這些資料通常也是一筆一筆的
那這樣通常會以怎樣的型式儲存在資料庫中呢？
我目前想到的做法
1. 另外開一個表存這些資料，用ID關聯
不過這樣每個玩家的資料就全部擠在一起，搜索起來效率應該相當不妙
2. 直接轉JSON塞進欄位
感覺比較可行，不過每次讀寫都要裝包拆包感覺不太靈活
可讀性應該也很悽慘
3. 為每個玩家開不同的表
比如說一個wix3000就有wix3000_units、wix3000_items之類的表
這樣在query的時候就可以簡單的隔開其他使用者了
嗯... 不過這方法看起來挺蠢的
不知道版友們有沒有更專業一點的作法
可以討論一下
作者:
damody (天亮damody)
2017-11-20 14:10:00另外nosql不一定比rds快 可以的話還是要測過
當然是1阿！2的風險很大，你的資料格式一改變就有可能讓舊資料壞掉3的話沒聽過這種用法，你會幾乎沒辦法做資料統計
作者:
damody (天亮damody)
2017-11-19 23:32:00就是1的方法 叫資料庫正規化不用3 現代資料庫優化的很好了 不要自作聰明 不會比較快一般vps可以每秒300到3000個query 寫個測試程式實際測比較快
作者:
wix3000 (癢，好吃)
2017-11-20 04:36:00居然是阿D師 有神快拜
作者:
b81314 (有點貴)
2017-11-21 09:11:00我不懂這有啥考慮 不就只有1嗎資料結構的觀點來看 2和3明顯是大忌
作者:
wix3000 (癢，好吃)
2017-11-21 21:48:00就... 覺得撈個資料要跑整張表感覺很慢 (?
光靠感覺不準，凡事profile最準，再者資料庫一定會用資料結構加速，不可能去跑整張表
作者:
hodsala (猴的沙拉)
2017-11-23 06:32:00就是1 SQL就是在做你說感覺很慢的這件事DB不是一筆一筆找的 覺得看表不好看就寫個view就好啦要到你覺得慢的話可能要到百萬筆 那時備份或換表就好了
作者:
LayerZ (無法如願)
2017-11-24 15:36:002跟3用index作?不過遊戲的話存必要資料就好，其他放記憶體，DB讀寫很慢像血量這種一直在變動的存DB會出人命
作者:
adcmhack (inhyo)
2017-12-19 02:18:00當然是1，搜尋慢就要優化囉