继续求知-这样的数据库如何设计比较好

Question

帮朋友设计一个游戏后台，这里设计到一个赔率的东西
游戏有10几种玩法，而每个玩法又设计到10-40个不同的赔率（不是只有一个不同赔率，而是有40个同时产生的不同赔率),同时赔率还根据购买者进行自动调整赔率。那么这样的数据表应该怎么设计比较合理?我现在是 每种游戏一个标准赔率表(可以让人工操作赔率) 也就是 类似基准参数 1.0然后每个玩家在购买时根据计算出的赔率再写到另外一个对应的即时赔率表内.但是我知道这样设计肯定太烂了.一个玩法就要产生3个表 基础赔率表/即时赔率表/购买情况表.
搜索计算的时候要搜索出购买情况->即时赔率或者基础赔率...赔率表设计的方式是游戏1
编号 游戏1-1赔率 游戏1-2赔率 游戏1-3赔率.... 购买时间 订单编号游戏2
编号 游戏2-1赔率 游戏2-2赔率 游戏2-3赔率.... 购买时间 订单编号 比如有15种游戏就要产生 3*15个表格出来....问题还不仅如此所以恳请大家出谋划策看看有没啥可指点的，多谢了

Answer 1

发到mysql 数据库区了，有知道的麻烦说一下 

Answer 2

赔率由什么引起变化？投注额么？
这个变化后的赔率对后来者都有效么？如果实际的博彩，即时赔率应该一个，如果同时有多个赔率存在，应该有某种联动范围控制
例如10/1.01, 100/1.5, 1000/1.8, 10000/2.0……n/封顶，或者sum(n)/封盘其实最好先自己画一下业务流程图，看看哪里需要数据交互，光这样说我们也是按自己的理解去猜而已

Answer 3

感谢大家的关注。赔率是有一定的公式的，但是总体就是根据投注额和投注人数来进行变动。具体公式我还未知。每一个博彩（购买）都可能会产生一个新的赔率，是的有封顶也有最低限.所以 我想知道类似于这样而且有很多赔率产生的数据如何规划这个库.全局的数组会很占内存吧？
为什么不是一个表，分3*15个字段？
因为15是15个GAME,每个GAME里又有 10-40个赔率数据根据博彩状态产生,而且几乎是动态变化的.

Answer 4

这样的话你的思路基本没错，优化一下表结构和SQL语句的技巧每单的数据量（字节）不大，考虑到投注人次多的时候，数据库的存取次数，最好减少入库完成订单的query次数
呵呵，越接近封盘的时间，单位时间内下单的人/次数可能几何级数增长另外投注额和动态赔率应该放在一起，这样读取方便也能避免两表数据不对应引起的差错另外要考虑特别情况（视客户需要），例如某（些）订单会被否决……诸如此类，数据库内可能要预留字段如果整个业务来看，事后的计算不是问题，重点问题是要放在减少在特定时间（例如临近封盘）数据库存取的次数