这里有几个问题/问题,所以我会尝试解决每个问题.
所有比赛互动应该是实时的/反映给许多用户.
对于您网站上的中小型流量,这可能不是问题.对于较重的流量,这将很快成为一个主要问题.
以您需要使用AJAX调用轮询数据库的频率为例.每一秒?因此,如果您有100个人打开一个页面,那么每秒有100个数据库调用?你会发现它会迅速杀死你的数据库.
即使这稍微偏离主题,我强烈建议您研究如何提前缓存锦标赛结果.您可以缓存统计数据等,让它们过期或过期使它们过期,但肯定会花一些时间来研究它.
实时统计/结果
请记住,连接在关系数据库中需要时间.如果你大规模地规范你的锦标赛结构,那么获得统计数据可能会很痛苦.系统中最难实现的部分是每场锦标赛的总量和统计数据.
在设计数据库/表/视图/存储过程时,请记住最终目标 – 快速获取统计信息.这可能意味着不会过多地规范化数据(以避免过多的连接).这也可能意味着要非常密切关注您的数据类型 – 例如使用位/短路/等.而不是整数.
如何模拟不同的锦标赛类型
我不熟悉锦标赛模型,但我确实对如何建模有具体的建议. =)
你应该问自己一些问题:
>所有锦标赛都有共同的领域吗?换句话说,对于循环赛,我们存储10个领域.对于单场淘汰赛,我们存储了11个领域.如果他们共享相同的10个字段,那么我建议将所有锦标赛类型放入一个表中,然后使用tournament_type字段来确定您的应用程序的锦标赛类型.>所有锦标赛都没有共同的领域吗?使它们成为单独的表 – 每种锦标赛类型一个.您可以为共享数据创建一个表,但是为特定信息设置不同的表.>随着时间的推移,锦标赛领域会分开吗?随着时间的推移,您需要为锦标赛类型添加字段.如果您预测锦标赛将随着时间的推移变得非常独特且非常具体,请将它们分开.否则,最终会出现大量具有大量NULL值的字段.>您考虑过NoSQL解决方案吗? NoSQL存储的好处在于它使数据非规范化,因此您没有连接.您也可以在同一“表”或容器中使用异构(不同类型的数据).只需考虑一下因为它可能会让您的生活变得更加轻松.以MongoDB为例.