出于标准化目的，关联这些表的最佳方式是什么？与一个实体的 2 个关系 vs 与另一个实体的 1 个关系答案

【问题标题】：For normalization purposes what is the best way of relating these tables? 2 relations to an entity vs 1 to another entity出于标准化目的，关联这些表的最佳方式是什么？与一个实体的 2 个关系 vs 与另一个实体的 1 个关系
【发布时间】：2021-06-28 19:03:24
【问题描述】：

请多多包涵，我对数据库和 SQL 还是很陌生。我正在校外从事一个项目，以制作入门级作品集。它是 Pokemon TCG 锦标赛结果与卡片数据和价格的关系数据库。我创建了一系列关系图，随着我抓取所需的数据并将它们实施到项目的表中，我一直在慢慢发展，实现了诸如“我在这里不需要这个，因为它可以通过这种关系推断出来”之类的事情。

但是，对于我的一个实体关系，我想将特定牌组的实体与牌组中的牌相关联。一副牌有很多张牌，一张牌可以在很多副牌中。为了表示我需要一个关联表。我称之为 DeckCards。话虽如此，在纸牌游戏中，套牌有两张定义套牌的主要卡牌，我想将其与卡组联系起来。基本上如果一个卡组在很多套牌中有很多关键卡，说明它是一个很好的卡组，应该有更高的价格。

起初我最初制作了一个关联表，想法是：“好的，一副牌最多有两套钥匙卡在其中，一套钥匙可以定义多副套牌的钥匙卡。

但这似乎不对。即使玩弄哪个实体拿到了钥匙卡似乎也不是什么好东西。我想也许与 Set 实体的关系权可能会起作用，但是我会丢失有关实际卡片是什么的信息。

所以我搜索了是否可以在实体之间建立多个关系，显然我可以。那么逻辑将是：一副牌有一张钥匙卡 1 和一张卡片 ID X 和一张钥匙卡 2 和卡片 ID Y。然后我可以将这些卡片与它们的集合 ID 等联系起来。我可以在同一个表中对同一个主键有多个外键吗？我的其他关联表会损害我的逻辑吗？

所以现在我有了这个。哪个可能是对的？但我想问你们，什么可能会更好，或者我是否做得对。

我非常感谢您提前提供的任何建议。如果您发现我在其他任何地方都错了，我很乐意听到。

【问题讨论】：

“钥匙卡”是否也是“套牌”的一部分，换句话说：是否所有与“套”相关的“卡”又与特定的“套牌”相关同一个“甲板”的“甲板卡”？
如果我阅读正确，我认为这是问题的正确答案。卡片列表中的两张卡片是钥匙卡。
哦，也许你是在暗示我应该在 DeckCard 实体中有钥匙卡？如果是这种情况，我将需要另一列来标识一张卡片是否是具有该特定套牌 ID 的钥匙卡！

标签： sql sql-server database database-design database-normalization

【解决方案1】：

我认为这两个选项都不正确。

我认为你有两个选择：

要么向DeckCards 添加一列，并为其设置过滤的唯一索引。

CREATE TABLE KeyDeckCard (
    DeckId int,
    CardId int,
    IsKey BIT NOT NULL,
    PRIMARY KEY (DeckId, CardId)
);

CREATE UNIQUE INDEX UX_DeckKey (DeckId) INCLUDE (IsKey) WHERE IsKey = 1;

或者更好：KeyDeckCard 的单独表，它具有与 DeckCards 完全相同的两列，主键和外键都指向 DeckCard。

CREATE TABLE KeyDeckCard (
    DeckId int,
    CardId int,
    PRIMARY KEY (DeckId, CardId),
    FOREIGN KEY (DeckId, CardId) REFERENCES DeckCard (DeckId, CardId)
)

【讨论】：