标准化表中的MySQL空单元格

时间:2014-07-31 18:58:03

标签: php mysql sql normalization

好的,关于这个主题的最后一篇文章(我希望)。我一直试图在我正在建立的网站中查看表格的规范化,而且我必须诚实地说我已经在努力解决这个问题,但是在我上一篇文章之后看来我可能会我们终于抓住了它并正确地设置了我的桌子。

然而,还有一个问题。如果我创建一个看似第三范式的表,如果数据与该特定表相关,是否可以使用空白区域或空单元格?让我举个例子:

在新闻网站上,我有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)。如你所知,不是每个人都有推特或wesbite或facebook,所以这些单元格的内容相当灵活,所以在某些情况下显然会出现空单元格。

有人建议以另一种方式这样做,所以我制作了:

链接

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

Author_Links

+----------+--------+------+
| 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);

3 个答案:

答案 0 :(得分:1)

至于我Authors_Table是正确的。

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

唯一原因有三个表:

作者

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

Link_types

| ID | TYPE |

Author_links

| AUTHOR_ID | LINK_TYPE_ID | URL |

...是你的作者可以拥有多个特定类型的链接(例如两个推特账户,顺便说一下,这是合法的吗?)

如果我们假设任何作者每个类型只能有一个帐户 - 您的单个表格版本是正确的。

答案 1 :(得分:1)

取决于功能要求,这两种方式都是可接受的。

如果您需要为配置文件动态添加更多网址类型/字段,请使用后者。

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

无需过度工程。

答案 2 :(得分:0)

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

只要模型中存在限制,属性将限制为单个值(单个Facebook页面,单个推特等),这些属性可以存储在实体表中。我们只使用NULL值来表示值不存在。

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