SQL数据库：使用一个包含3,5M条目的表或使用条目较少的表吗？

Question

我正在制作一个足球游戏，让人们可以在线创建联赛。

说一段时间后我有1000个联赛。我将数据存储在SQL中。我应该：

1）创建1个与表“名册”单一数据库和所有联赛的所有球员插入它（这将接近3.5至4万个条目，1000个盟）

2 ）创建1个20代表“rosters1，rosters2等”单个数据库和拆分那些20个表之间的联赛名册

3），用于在与表“名册”每个联盟创建1个数据库中的每个

4）创建20个数据库，每个数据库中有一个表“花名册”，并在20个数据库之间拆分联盟名册。

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

Answer 1

听起来你需要学习一些数据库基础知识，所以请花点时间确保你了解Database Normalization和indexes。然而，原则上，你可能需要一个“玩家”表（玩家ID，名字等），一个“名册”表（名册ID，名字，也许是owner_id）和一个player_roster_map（player_id，roster_id）将两者联系起来。您可能需要对player_id和roster_id的复合值进行唯一约束，并且您应该在该映射表中对player_id和roster_id都有外键约束。 （我假设球员并不是每个球员都是独一无二的;如果有属性被拥有球员的人所覆盖，那么你仍然可以进行类似的模拟，但是我猜根据我对你对球员的描述的理解该模型）

您的数据库引擎可能会将您标记为主键的任何内容编入索引，并且可能将您标记为外键的任何内容编入索引，但这依赖于数据库，并且我不是专家在MySql上;你需要做一些研究。

当您执行查询时，正确的索引将帮助您，插入性能方面的成本通常较低。如果最后得到大量相同的值或者查询的利用率很高（只有一小部分值（例如时间范围）），那么您最终可能还需要了解分区。分区使您可以获得处理大量记录的好处，而不会产生非规范化引入的建模问题。但是，不要过早地采取这一步骤;您可能会发现，正确的数据库设计对于您所暗示的数据集的大小已足够。

Answer 2

我想你想要选项1原则上。你必须考虑使用情况，例如将某个人从一个名单移到另一个名单：你不希望跨数据库发生这种情况。我想像你想要对阵所有名单的许多问题。尽管MySQL不提供它，但您可能会发现研究分区很有帮助。 （Postgresql的）

你还需要看看规范化。例如：我假设你有一个teams表，并且PlayerTeam只是一个外键（你应该在这两个表中将这个列索引）。如果这对您没有意义，请花一点时间在数据库设计书或网站上。