规范化表中的 MySQL 空单元格

Question

好的，关于这个主题的最后一篇文章（我希望）。我一直在尝试研究我一直在构建的网站中表格的规范化，老实说我一直在努力解决它，但是在我上一篇文章之后，似乎我终于掌握了它并设置我的桌子正常。

但是，还有一个问题。如果我创建一个看似第 3 范式的表格，如果数据与该特定表格相关，是否可以接受有空白区域或空单元格？举个例子吧：

在新闻网站上我有一个Authors_Table

+----+-----------+----------+-----------------+-------------------+---------+----------+---------+
| ID | FIRSTNAME | SURNAME  | EMAIL           | BIO ( REQUIRED )  | TWITTER | FACEBOOK | WEBSITE |
+----+-----------+----------+-----------------+-------------------+---------+----------+---------+
| 01 | Brian     | Griffin  | brian@gmail.com | About me...       | URL     |          | URL     |
| 02 | Meg       | Griffin  | meg@gmail.com   | About me...       | URL     |          |         |
| 03 | Peter     | Griffin  | peter@gmail.com | About me...       |         | URL      | URL     |
| 04 | Glen      | Quagmire | glen@gmail.com  | About me...       | URL     | URL      |         |
+----+-----------+----------+-----------------+-------------------+---------+----------+---------+

这将用于article 页面，以提供有关作者的一些详细信息，这在报纸和现代博客中很常见。现在最后 3 列 Facebook, Twitter, Website 显然与作者相关，因此与 PK (ID) 相关。正如你所知道的，并不是每个人都有 twitter 或 wesbite 或 facebook，所以这些单元格的内容相当灵活，因此在某些情况下显然会出现空单元格。

有人建议用另一种方式做，所以我制作了：

链接

+----+-------------------+
| ID | TYPE              |
+----+-------------------+
| 01 | Facebook          |
| 02 | Twitter           |
| 03 | Website           |
+----+-------------------+

作者链接

+----------+--------+------+
| AUTHOR   | TYPE   | LINK |
+----------+--------+------+
| 01       | 01     | URL  |
| 01       | 02     | URL  |
| 01       | 03     | URL  |
| 02       | 02     | URL  |
| 02       | 03     | URL  |
| 03       | 01     | URL  |
+----------+--------+------+

现在我理解了这个概念，但是拥有和使用原始表不只是“正确”吗？可以使用表单和 php 进行更新：

$update_link_sql = "UPDATE authours SET facebook = ' NEW VALUE ' WHERE id = '$author_id'";
$update_link_res = mysqli_query($con, $update_links_sql);

Answer 1

是的，将“可选”属性存储为实体表中的列是“正确的”。只是当我们有重复的值时，例如例如，我们想要实现子表的作者的多个 facebook 页面。 （我们不想在实体表中存储“重复”属性。）

只要模型中有限制，属性将被限制为单个值（单个 facebook 页面、单个 twitter 等）。这些属性可以存储在实体表中。我们只需使用 NULL 值来指示值不存在。

单独表格方法的一个好处（在您的帖子中概述）是添加新“类型”的 URL 会“更容易”。例如，如果将来我们想要存储 blogspot URL 或 instagram URL，而不必修改实体表来添加新列，我们可以简单地向“link_type”表和“author_link”表添加行。这是最大的好处。

Answer 2

根据功能要求，任何一种方式都可以接受。

如果您需要动态添加更多 url 类型/字段到配置文件，请使用后者。

如果只有 3 个，那么前者更好。

无需过度设计。

Answer 3

对我来说 Authors_Table 是正确的。

| ID | FIRSTNAME | SURNAME | EMAIL | BIO ( REQUIRED ) | TWITTER | FACEBOOK | WEBSITE |

拥有三个表的唯一原因：

作者

| ID | FIRSTNAME | SURNAME  | EMAIL | BIO ( REQUIRED )  |

链接类型

| ID | TYPE |

作者链接

| AUTHOR_ID | LINK_TYPE_ID | URL |

...您的作者是否可以拥有多个特定类型的链接（例如两个 Twitter 帐户，顺便说一句，这是否合法？）

如果我们假设任何作者对于每种类型最多只能拥有一个帐户 - 你的单表版本是正确的。