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

黄袍披身 2011-05-10 09:47:33
帮朋友设计一个游戏后台,这里设计到一个赔率的东西
游戏有10几种玩法,而每个玩法又设计到10-40个不同的赔率(不是只有一个不同赔率,而是有40个同时产生的不同赔率),同时赔率还根据购买者进行自动调整赔率。

那么这样的数据表应该怎么设计比较合理?

我现在是 每种游戏一个标准赔率表(可以让人工操作赔率) 也就是 类似基准参数 1.0

然后每个玩家在购买时根据计算出的赔率再写到另外一个对应的即时赔率表内.

但是我知道这样设计肯定太烂了.一个玩法就要产生3个表 基础赔率表/即时赔率表/购买情况表.
搜索计算的时候要搜索出购买情况->即时赔率或者基础赔率...

赔率表设计的方式是

游戏1
编号 游戏1-1赔率 游戏1-2赔率 游戏1-3赔率.... 购买时间 订单编号

游戏2
编号 游戏2-1赔率 游戏2-2赔率 游戏2-3赔率.... 购买时间 订单编号

比如有15种游戏就要产生 3*15个表格出来....问题还不仅如此。。。

所以恳请大家出谋划策看看有没啥可指点的,多谢了


...全文
45 2 打赏 收藏 转发到动态 举报
写回复
用AI写文章
2 条回复
切换为时间正序
请发表友善的回复…
发表回复
rucypli 2011-05-11
  • 打赏
  • 举报
回复
玩法表
赔率表
玩家表
wwwwb 2011-05-11
  • 打赏
  • 举报
回复
游戏id 游戏赔率id 购买时间 订单编号 ....

游戏表
游戏id 游戏名称

游戏赔率表
游戏赔率id 赔率

56,679

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧