连接表的好处?

Mar*_*ear 0 sql relational-database

我试图向同事解释连接表的好处,下面是一个解释。我对么?

目前他有两张表的图片和标签之间的关系。一个图片表和一个标签表。pic 表有一个tag_id这是标记表中条目的 FK。这是我的回应:

首先让我们看看picstags表。因此,在您当前的架构中,让我们想象两张图片(a 和 b)。我们用#wtf标签标记图片a和b。我们现在在 outtags表中有两个条目:

pic_id  title
------  -----
a       wtf
b       wtf
Run Code Online (Sandbox Code Playgroud)

你看到问题了吗?所以想象一下,我们在 1000 张不同的图片上有 1000 个 wtf 标签。使用相同的架构,我们现在有一个臃肿的标签表,其中包含所有这些重复数据(和浪费的空间)。当我们有多对多关系时,就会出现这个问题。在这种情况下,很多图片可以有很多标签,很多标签可以有很多图片。我们将如何解决这个问题?答案是连接表。所以我们创建了一个新表。让我们称之为pic_tag。该表将包含列pic_id& tag_id。所以现在新表看起来像:

图片标签

pic_id  tag_id
------  ------
a       1
b       1
Run Code Online (Sandbox Code Playgroud)

标签

id   name
--   ----
1    wtf
Run Code Online (Sandbox Code Playgroud)

图片

id  name
--  ----
a   pic1
b   pic2
Run Code Online (Sandbox Code Playgroud)

所以这对我们做了几件事。首先它节省空间。我们只存储字符串 'wtf' 一次。其次,要找到所有带有标签“wtf”的图片,我们首先转到标签表并找到“wtf”的 id,然后转到 pic_tag 表并搜索该 id,这比搜索臃肿的“标签”要高效得多' 给定文本的表格。换句话说,搜索整数比搜索文本快得多。

Chr*_*son 5

主要好处是有些关系只能用连接表建模。

假设您有两个实体 A 和 B。如果关系 A:B 是 1:1,则这两个实体可以用一个表来表示。如果 A:B 是 1:N(例如 1 个客户可以有 N 个订单,但每个订单仅来自一个客户),那么您可以将其建模为从订单表到客户表的外键。但是如果 A:B 是 N:M(你的标签场景是一个很好的例子)你需要一种方法来表示每张图片的 0、1 或 N 个标签。除了连接表之外,没有其他可靠的关系表示。

请注意,您可以在每列中表示多个标签,同时打破关系设计的一些原则(例如存储多个标签或 FK 到标签)。是否这样做是一个设计决定。

其他好处:您可以改变关系是 0:1、0:N、1:(0-5)、1:N 等,而无需更改核心数据模型——在触发器或应用程序逻辑中解决该逻辑。您可以创建其他索引来帮助连接。您可以引入更多唯一性约束来强制执行数据逻辑等。

但主要的好处是,连接表是对某些类型的关系建模的唯一关系良好的方法。