嗯... 虽然感觉用noSQL可以很轻松解决
不过暂时还是只有MySQL可以用
想请问一下，假设做一款网络手游
每个玩家都会有很多的资料，比如说拥有的卡片、编队、某某任务的进度，道具数量等等
这些资料通常也是一笔一笔的
那这样通常会以怎样的型式储存在数据库中呢？
我目前想到的做法
1. 另外开一个表存这些资料，用ID关联
不过这样每个玩家的资料就全部挤在一起，搜索起来效率应该相当不妙
2. 直接转JSON塞进字段
感觉比较可行，不过每次读写都要装包拆包感觉不太灵活
可读性应该也很悽惨
3. 为每个玩家开不同的表
比如说一个wix3000就有wix3000_units、wix3000_items之类的表
这样在query的时候就可以简单的隔开其他使用者了
嗯... 不过这方法看起来挺蠢的
不知道版友们有没有更专业一点的作法
可以讨论一下

另外nosql不一定比rds快 可以的话还是要测过

当然是1阿！2的风险很大，你的资料格式一改变就有可能让旧资料坏掉3的话没听过这种用法，你会几乎没办法做资料统计

就是1的方法 叫数据库正规化不用3 现代数据库优化的很好了 不要自作聪明 不会比较快一般vps可以每秒300到3000个query 写个测试程式实际测比较快

居然是阿D师 有神快拜

我不懂这有啥考虑 不就只有1吗资料结构的观点来看 2和3明显是大忌

就... 觉得捞个资料要跑整张表感觉很慢 (?

光靠感觉不准，凡事profile最准，再者数据库一定会用资料结构加速，不可能去跑整张表

就是1 SQL就是在做你说感觉很慢的这件事DB不是一笔一笔找的 觉得看表不好看就写个view就好啦要到你觉得慢的话可能要到百万笔 那时备份或换表就好了

2跟3用index作?不过游戏的话存必要资料就好，其他放内存，DB读写很慢像血量这种一直在变动的存DB会出人命

当然是1，搜寻慢就要优化囉