“梦幻足球”数据库中结果表的正确数据库结构答案

【问题标题】：Correct database structure for a results table in a 'fantasy football' database“梦幻足球”数据库中结果表的正确数据库结构
【发布时间】：2016-10-17 10:39:56
【问题描述】：

在这个场景中，我有：球员、梦幻足球联赛（社区）和结果。

1 位用户可以加入许多梦幻联盟。

我目前的结构是：

create table players (id int, email, display_name)
create table communities (id int, name, password, admin_email)
create table community_players (community_id, player_id)

我现在需要为每个社区创建一个结果表。我在想：

create table results (player1_id, player1_points, player1_goals_scored, player2_id, player2_points, player2_goals_scored, date, community_id)

我担心这张桌子最终会变得很大。因此，当我对其进行统计查询时（例如，谁击败了谁、进球数、失球数等），它最终会变得异常缓慢。

我的想法是：

我应该为每个创建的社区“即时”创建结果表吗？

create table results_community_name (player1_id, player1_points, player1_goals_scored, player2_id, player2_points, player2_goals_scored, date, community_id)

【问题讨论】：

为另一个表中的每条记录创建一个表是一个众所周知的坏主意。你现在的结构到底有什么问题？您对其性能和可扩展性有什么衡量或估计？
我不想为另一个表中的每条记录创建一个表，只是在数据库中 - 或者这就是你的意思？我没有任何测量或估计，除非我只使用一张表，我估计它在提取进球数等统计数据时可能会查询大约 100,000 条记录。
"create a results table 'on-the-fly' for every Community" - 这是否意味着您将为communities 表中的每条记录创建一个表？至于记录数，只有整数的表中的 100,000 条记录是相当少的数据量。
100,000 条记录是小菜一碟。等到你增长到那个大小的 100 倍。然后开始担心性能。
大卫 - 是的。对不起，我以为你的意思不同。我仍在研究数据库结构！

标签： mysql database database-design ddl

【解决方案1】：

数据库是为存储行而构建的。很多行。通过适当的索引和维护，您永远不会真正遇到性能问题。另一方面，为每个社区创建一个表不仅会使您的代码复杂化，而且很快就会成为维护的噩梦。

如果性能真的成为问题，您应该查看 MySQL 的partitions。本质上，它创建了 N 个隐藏在一个逻辑表后面的物理表，这有点像您为每个社区创建一个表的想法，但管理方式要容易得多。

【讨论】：

谢谢，我想在您和 Davids cmets 之后，我将使用单个结果表
results_table 是否需要它自己的 'id' 列？