mysql - SQL 数据库 : use one table with 3, 5M 条目或条目较少的许多表？

Question

我正在开发一款允许人们在线创建联赛的足球游戏。

假设一段时间后我有 1000 个联盟。我将数据存储在 SQL 中。我应该:

1) 创建一个带有“rosters”表的单一数据库，并将所有联赛的所有球员插入其中(对于 1000 个联赛，大约有 3.5 到 4 百万个条目)

2) 创建一个包含 20 个表“rosters1、rosters2 等”的单一数据库，并将联赛名册拆分到这 20 个表中

3) 为每个联盟创建 1 个数据库，每个数据库都有一个表“rosters”

4) 创建 20 个数据库，每个数据库有一个表“rosters”，并将联赛名册拆分到 20 个数据库中。

性能和快速 SQL 查询的最佳选择是什么？

Answer 1

听起来您首先需要学习一些数据库基础知识，所以请花一些时间确保您理解 Database Normalization和 indexes .

但是，原则上，您可能需要一个“玩家”表(玩家 ID、姓名等)、一个“名册”表(名册 ID、姓名，也许是所有者 ID)和一个链接的 player_roster_map(player_id、roster_id)他们俩。您可能需要对 player_id 和 roster_id 的复合值进行唯一约束，并且您应该对该映射表中的 player_id 和 roster_id 进行外键约束。

(我假设每个名册的球员并不是真正独一无二的；如果拥有他们的人覆盖了某些属性，您仍然可以进行类似的建模，但我是根据我对您对模型。)

默认情况下，您的数据库引擎可能会索引您标记为主键的任何内容，并且可能会索引任何您标记为外键的内容，但这是依赖于数据库的，我并不是 MySql 的专家；你需要做一些研究。

适当的索引将在您执行查询时为您提供帮助，而且在插入性能方面的成本通常很小。如果您最终得到大量相同的值或查询的利用率很高，其中只有一小部分值(例如时间范围)，您最终可能还需要了解分区。分区允许您获得处理大量记录的好处，而不会出现非规范化会引入的建模问题。但是，不要过早地采取这一步；您可能会发现正确的数据库设计足以满足您所暗示的数据集的大小。