最有效，可扩展的mysql数据库设计

Question

我对数据库设计有一个有趣的问题：

我提出以下设计：

第一张桌子：

**Survivors:**

Survivor_Id | Name | Strength | Energy

第二张表：

**Skills:**

Skill_Id | Name

第三张表：

**Survivor_skills:**

Surviror_Id |Skill_Id | Level

在第一个表格中，幸存者会有很多记录，并且会不时增长。 在第二张表中，只有少数幸存者可以学习的技能（例如：重新坐姿（视野范围更大），狙击手（精度更高）...）。 这些技能并不像所有幸存者都拥有的力量或精力。 第三张桌子是最有趣的，幸存者和技巧在此齐聚。 一切都会正常，但我担心数据重复。

例如：ID为1的幸存者将拥有5种技能，因此第一个表格如下所示：

// survivor_id | level_id | level
1 | 1 | 2
1 | 2 | 3
1 | 3 | 1
1 | 4 | 5
1 | 5 | 1

第一条记录：ID为1的幸存者在2级时具有ID为1的技能第二条记录...

这是正确的方法还是应该使用其他方法？

Answer 1

对我来说看上去很好。 如果您担心数据重复：

1）您的服务器端代码应适应这种情况

2）您可以在插入之前检查是否已经存在

3）您可以使用MYSQL：REPLACE INTO-如果进行适当的配置，它将替换重复的行，或者插入新的行（ http://dev.mysql.com/doc/refman/5.0/en/replace.html ）

4）在只需要唯一行的列上设置唯一索引，例如level_id，level

Answer 2

我同意其他人的看法-这是正确的做法。

但是，有一个方面尚未讨论：组合键{Surviror_Id，Skill_Id}中的列顺序，这将由您需要运行的查询种类决定...

• 如果需要查找给定幸存者的技能，则顺序为：{Surviror_Id，Skill_Id}。
• 如果您需要找到具有给定技能的幸存者，则顺序为：{Skill_Id，Surviror_Id}。
• 如果同时需要两者，则将同时需要{Surviror_Id，Skill_Id}上的键（和隐含索引）， 以及 {Skill_Id，Surviror_Id} ¹上的索引。 由于InnoDB表是集群的 ，因此通过该二级索引访问Level时需要两次查找-为避免这种情况，请考虑改用覆盖索引{Skill_Id，Surviror_Id，Level}。

---

¹或反之。