关系数据库设计 - 规范化和关系答案

【问题标题】：relational database design - normalization and relationships关系数据库设计 - 规范化和关系
【发布时间】：2016-07-03 00:45:30
【问题描述】：

我是设计数据库的新手，我不确定我在为我的应用程序设计数据库时是否正确实现了规范化和关系。

正在设计的应用程序与购物清单和产品一起使用，并将按如下方式使用数据库：

用户通过 facebook 登录网站。
有一个包含数百万“产品代码”的大表。每个产品代码代表不同的产品（例如 Apple、电视、手机、牙刷等）。
用户可以创建各种购物清单，每个购物清单都包含一个或多个“产品代码”。

我“尝试”为数据库创建了两种不同的设计，以尝试推断哪一种可能更适合该场景。一种使用一对多关系，一种使用多对多关系，两者都将 shopping_list 链接到 product：

问题：

关于一对多：鉴于会有数百万个不同的产品 ID，一对多设计不会产生大量冗余assigned_products 表中的信息？ products 表的字段类似于：

 ________________________________________________
|assigned_p_id | shopping_list_id | product_code |
|--------------+------------------+--------------|
|      1       |        1         |   aa11aab    |
|--------------+------------------+--------------|
|      2       |        1         |   zz1bbbb    |
|--------------+------------------+--------------|
|      3       |        2         |   aa11aab    |

如您所见，aa11aab 重复了两次，因为其他人使用相同的商品创建了购物清单，因此我想知道这种冗余是否会导致数据库出现问题，因为每个重复的 product_code 都会占用大量不必要的空间？

关于多对多：该图似乎通过让表 shopping_list_products 存储 id 值而不是重复 product_code 来消除冗余，但是，这会在检索信息时导致性能损失吗？我假设必须在表格之间进行一些连接，以便每个用户都可以获取他们的所有购物清单以及该购物清单中的产品代码。
一般来说：我的关系/正常化可能有任何错误吗？（我是这方面的新手）

【问题讨论】：

所以你的第二张图解决了这个问题，因为产品对用户来说应该是不可知的，并且没有逃避使用 shopping_list 和产品之间的桥梁关系，这完全没问题。没有桥表购物清单和产品永远不会互相认识。
Shopping_list_products 也需要一个pk。就目前而言，它应该是两个fks。你可能也想要一个数量。
@LoztInSpace 我对设计数据库有点陌生 :)，所以“Shopping_list_products”会包含它自己的自动递增 ID（这将是它的主键）。还重新定义“两个 fks”，你的意思是我在那个表中有两个外键吗？我什至不确定这是否可能（MySQL 服务器允许）
不需要自己的 id，是的 2 fks
重新 "id 值而不是重复 product_code" Ids 和 product_codes 都只是值。后者没有“冗余”。在给定的 DBMS 中，可能会引入 id 进行优化。规范化不涉及引入新的列名。

标签： php mysql database relationships database-normalization

【解决方案1】：

这里有一些关于从哪里开始的建议。

您需要一个表格来存储有关购买的信息。在数据中，您可以看到 Wile E Coyote 购买了 Dyno-might 和 Piano...

CREATE TABLE IF NOT EXISTS `purchase` (
    `id`           int unsigned      NOT NULL AUTO_INCREMENT,
    `user_id`      int unsigned      NOT NULL,
    `item_id`      int unsigned      NOT NULL,
    `quantity`     double            DEFAULT 1,
    `price`        double            NOT NULL,
    `qwhen`        datetime          NOT NULL,
    PRIMARY KEY (`id`),
    FOREIGN KEY (`user_id`) REFERENCES user(id) ON DELETE RESTRICT ON UPDATE CASCADE,
    FOREIGN KEY (`product_id`) REFERENCES product(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB Comment='Purchases';

purchase data
+----+---------+------------+----------+--------+---------------------+
| id | user_id | product_id | quantity |  price | created             |
+----+---------+------------+----------+--------+---------------------+
|  1 |       1 |          1 |        1 | 100.00 | 2016-07-02 20:42:13 |
|  1 |       1 |          3 |        1 | 734.23 | 2016-07-02 21:23:40 |
| .. | ....... | .......... | ........ | ...... | ................... |
+----+---------+------------+----------+--------+---------------------+

您还需要一个表格来存储有关产品的信息。我假设您在销售实体产品，所以我添加了 ean、upca 和其他一些可能有用的列。

CREATE TABLE IF NOT EXISTS `product` (
    `id`                 int unsigned      NOT NULL AUTO_INCREMENT,
    `manufacturer_id`    int unsigned      NOT NULL,
    `ean`                int unsigned      NOT NULL,
    `upca`               int unsigned      NOT NULL,
    `upce`               int unsigned      NOT NULL,
    `name`               varchar(100)      NOT NULL,
    `height`             double            DEFAULT NULL,
    `width`              double            DEFAULT NULL,
    `depth`              double            DEFAULT NULL,
    `weight`             double            DEFAULT NULL,
    PRIMARY KEY (`id`),
    FOREIGN KEY (`manufacturer_id`) REFERENCES manufacturer(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB Comment='Item master file';

product data
+----+-----------------+---------------+--------------+--------+------------+--------+-------+-------+--------+
| id | manufacturer_id | ean           | upca         | upce   | name       | height | width | depth | weight |
+----+-----------------+---------------+--------------+--------+------------+--------+-------+-------+--------+
|  1 |               1 | 1234567890123 | 123456789012 | 123456 | Dyno-might |   12.0 |   1.0 |   1.0 |    0.5 |
|  2 |               1 | 2345678901234 | 234567890123 | 234567 | UltraLaser |   96.0 |  96.0 |  96.0 |  450.0 |
|  3 |               2 | 3456789012345 | 345678901234 | 345678 | Piano      |   36.0 |  60.0 |  72.0 |  375.0 |
| .. | ............... | ............. | ............ | ...... | .......... | ...... | ..... | ..... | ...... |
+----+-----------------+---------------+--------------+--------+------------+--------+-------+-------+--------+

当我们向人们推销商品时，最好正式地称呼他们，因此我们应该有一张有效的称呼表。 user 表将具有该表的外键。

CREATE TABLE IF NOT EXISTS `salutation` (
    `id`           varchar(5)     NOT NULL,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB Comment='Salutations';

salutation data
+------+
| id   |
+------+
| Mr.  |
| Mrs. |
| Miss |
| Ms.  |
| Dr.  |
| Rev. |
| .... |
+------+

姓名后缀是人名的一部分，因此我们将把它作为user 表的一部分，并为该表提供一个外键。

CREATE TABLE IF NOT EXISTS `suffix` (
   `id`           varchar(5)     NOT NULL,
   PRIMARY KEY (`id`)
) ENGINE=InnoDB Comment='Suffixes';

suffix data
+-----+
| id  |
+-----+
| Sr. |
| Jr. |
| II  |
| III |
| IV  |
| ... |
+-----+

当然，我们也有用户——尽管称他们为客户可能更合适。

CREATE TABLE IF NOT EXISTS `user` (
    `id`              int unsigned   NOT NULL AUTO_INCREMENT,
    `facebook_id`     int unsigned   NOT NULL,
    `email`           varchar(255)   NOT NULL,
    `salutation_id`   varchar(5)     NOT NULL,
    `first_name`      varchar(50)    NOT NULL,
    `middle_name`     varchar(50)    DEFAULT NULL,
    `last_name`       varchar(50)    NOT NULL,
    `suffix_id`       varchar(5)     DEFAULT NULL,
    PRIMARY KEY (`id`),
    FOREIGN KEY (`salutation_id`) REFERENCES salutation(id) ON DELETE RESTRICT ON UPDATE CASCADE,
    FOREIGN KEY (`suffix_id`) REFERENCES suffix(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB Comment='Users';

user data
+----+-------------+------------------------+---------------+------------+-------------+-----------+-----------+
| id | facebook_id | email                  | salutation_id | first_name | middle_name | last_name | suffix_id |
+----+-------------+------------------------+---------------+------------+-------------+-----------+-----------+
|  1 |   123456789 | coyote_guy32@gmail.com | Mr.           | Wile       | E           | Coyote    | NULL      |
| .. | ........... | ...................... | ............. | .......... | ........... | ......... | ......... |
+----+-------------+------------------------+---------------+------------+-------------+-----------+-----------+

【讨论】：

【解决方案2】：

在这两种情况下，您基本上都在做同样的事情。在第一种情况下，您将shopping_list_id 映射到product_code，在第二种情况下，您将其映射到product_id。无论您使用product_code 还是product_id，它们似乎都是代表product 实体的外键。在这两种情况下，要到达产品行，您必须使用该字段加入 products 表。

作为一般规则，您应该映射两个 id 列（您的第二个选项），以便在这两种情况下都使用整数主键完成连接。这不仅可以提高存储和索引的效率，还可以使这些连接更快。

另外，正如其中一位 cmets 所指出的，您应该将自动增量主键添加到 shopping_list_products 表中。

附带说明，对于命名约定，您可能需要考虑始终使用id 命名主键。例如，不是products.product_id，而是每个表都有products.id等等。

【讨论】：