在这种情况下，非规范化表是可接受的选择吗？答案

【问题标题】：Is denormalized table an acceptable option in this case?在这种情况下，非规范化表是可接受的选择吗？
【发布时间】：2018-05-30 09:15:51
【问题描述】：

我想听听您对使用哪种表结构的意见。

假设这是一个存储 nba 球员信息的表格。所以你会有id, name, team_id等。

但是为了存储球员的位置（控球后卫、大前锋、中锋等），我是否应该创建一个单独的Player_Position 表将Player_ID 连接到Position？

播放器表：

ID      Name       Team_ID
-------------------------
1    LeBron James    10
2    CJ McCollum     5

Player_Position表格：

Player_ID  Position
-------------------
  1          PG
  1          SF
  1          PF
  2          PG
  2          SG

另一种选择是将PG, SG, SF, PF, C 列作为Players 表上的列，因此如果玩家玩PG 和SG，这些字段将为1，其他字段为0。

播放器表：

ID     Name          Team_ID   PG  SG  SF  PF  C
-------------------------------------------------
1   LeBron James      10       1   0   1   1   0
2   CJ McCollum       5        1   1   0   0   0

Player 至少有 1 个位置，可以是多个，（可以是全部 5 个）。以后不会发明新的职位，也不会删除，只有那5个。

【问题讨论】：

您的第一个Player_Position 表已标准化，并且比第二个为每个位置具有单独列的表更可取。对于第一个表，您可能还需要添加时间信息，例如这段关系代表哪个季节。
谢谢，我应该补充一点，我可能会手动编辑这些位置，所以我更喜欢第二个选项。所以我的问题变成了标准化表有哪些其他选项没有的明显优势？
我不确定在这两种情况下编辑是否更容易。第二种选择也有一个很大的缺陷，那就是如果你需要新的职位，那么你必须采取相当严厉的行动来添加新的列。
是的，我大体上同意。但是，在这种特殊情况下，正如我在最初的问题中提到的那样“以后不会发明新职位，也不会删除任何职位，只有那 5 个。”我想我只是想证明使用“坏”模式是合理的，因为我手动编辑会更容易。（是的，在第二个选项中编辑会更容易）。但你是对的，第一个选择是正确的方法。谢谢蒂姆
第二个表对性能很有用，但对更改和一般查询最不灵活。如果您已经遇到性能问题，那么也许考虑这个非规范化选项，也许作为派生表，但不是以前。一般来说，这将是过早的优化，您的收益可能非常微不足道，您会将自己锁定在未来的困难中，并且它们可能会引入真正的性能成本。不要这样做，尽可能长时间保持规范化，如果你需要去规范化，保持两者，一个派生自另一个......恕我直言

标签： mysql database database-design database-schema

【解决方案1】：

考虑这一列：

positions SET('PG', 'SG', 'SF', 'PF', 'C') NOT NULL

考虑设置/更改/获取数据的查询。然后阅读文档以了解您必须使用 SET 的扭曲方式。

【讨论】：