MySQL表设计和规范化帮助

注：该问题已于2012年11月19日重新表述，以供澄清。我在这里通常没有太多问题，但在为客户站点设计新产品系统时遇到了困难。我们提供一套产品，每个客户都可以销售给他的客户。我们可以随时添加新产品，但它们都遵循以下格式：

类别

类型

产品

要使用前面的结构给出一个实际示例：

• 棒球器材
  • 手套
    • 罗林斯
    • 耐克
    • 水泽
  • 蝙蝠
    • 伊斯顿
    • 路易斯维尔击球手
• 足球器材
  • 鞋
    • 耐克
    • 锐步
    • 阿迪达斯
  • 足球
    • 耐克
    • 萨普丁
    • 威尔逊
....

上面的列表显然还在继续，可能会大得多，但它给出了总体思路

目前，我将特定客户可以销售的产品类型存储在一个平面表格中，如下所示：

ID  | clientID | categoryID | typeID | productID | customURL
=============================================================
1   |  111     |    1       |   1    |   1       | 1111
2   |  111     |    1       |   2    |   2       | 2222
3   |  111     |    1       |   2    |   3       | 3333
4   |  111     |    2       |   3    |   4       | 4444
5   |  222     |    1       |   1    |   1       | 5555
6   |  222     |    2       |   3    |   4       | 6666

• 在上述示例中，类别1可以是“棒球设备”，类别2可以是“足球设备”
• 相应categoryID、typeID和productID的名称将存储在3个具有FK关系（innodb）的seaprate表中，以保持规范化
• 类型指第二级物品（手套、蝙蝠、鞋子、足球等）。这些数字从不相交（这意味着即使通用产品相同，也不可能有相同的typeID（棒球鞋的id与足球鞋的id不同）
• 在此表中，clientID 1可以销售4种产品，其中3种在类别1中，1种在类别2中。clientID 2可以销售2种产品，每个类别一种

我倾向于保持表格的结构化，但我知道在其他设计中，我可能为了规范化的目的而将表格分开，我不确定是否适用于这里。如果我将它们分开，我会看到从一个表格到4个或更多个表格，如下所示：

ID  | clientID | categoryID | typeID | productID | customURL
=============================================================
1   |  111     |    1       |   1    |   1       | 1111
2   |  111     |    1       |   2    |   2       | 2222
3   |  111     |    1       |   2    |   3       | 3333
4   |  111     |    2       |   3    |   4       | 4444
5   |  222     |    1       |   1    |   1       | 5555
6   |  222     |    2       |   3    |   4       | 6666

提供的产品表 产品定义表 类型定义表 分类定义表

---

我是否考虑过了？这两种方法不是都以相同的方式获得最终解决方案（后者只涉及几个连接来收集平面表，如图1所示）？

在第一种方法中，您忘记了每个类别、类型和产品id的名称列。如果您添加此信息，它可以工作，但另一种方法似乎已经工作。当您使用4个不同的表时，您有更多的空间。

我会选择标准化方法，因为您必须为类别和类型维护单独的查找表不管怎样，都要使用平面方法来命名（可能还有其他属性）

您可以考虑使用诸如：

的表将类别和类型更改为一般的树结构。

 create table product_hierarchy(
    id integer primary key,
    name character,
    parent_id references product_hierarchy)

---

…因为这将使客户能够灵活地增加层次结构的深度。

要尝试解决您的直接问题：

我是不是想得太多了

这取决于你的应用程序有多大，以及你使用什么引擎来存储数据。因为你计划把它放到MySQL表中，所以你的想法非常合适

这两种方法不是都以相同的方式得到最终解决方案吗（后者只是 涉及多个联接以收集平面表（如图1所示）

嗯，是的，但是

数据库规范化是组织字段和数据的过程 关系数据库的表，以最小化冗余和依赖性。 规范化通常涉及将大型表划分为较小的（和 减少冗余）表并定义它们之间的关系 目标是隔离数据，以便添加、删除和删除 只需在一个表中修改字段，然后 通过定义的 关系

---

将您的数据分解为您描述的结构（顺便说一句，我同意），将使您能够最轻松地维护您的数据。将类别和类型数据保留在与“提供的产品”相同的表中创建大量冗余数据。诚然，我无法想象在何处需要更新这些数据，但如果需要，则必须更新大量记录。在您建议的结构中，要更新的记录数是最少的。

规范化的目的和好处是使其更难（理想情况下，不可能）输入异常数据

例如，在图1中，如何防止意外存储typeid为3、categoryid为1的行？除了编写绝对完美的应用程序代码外，什么都没有

但如果使用单表方法，并且必须更改typeid 3的父类别，则必须更改一百万个位置的数据以反映更改。这意味着在执行清理时锁定表，否则可以同时插入新数据

规范化有助于消除冗余存储信息，如果每个离散事实（例如typeid 3属于categoryid 2）只存储一次，则很容易进行原子更改，并自动更改对该行的所有引用的含义

你说得对，需要更多的联接——但前提是你像现在这样到处使用伪键。你不一定需要这样做，你可以使用自然键，对它们的引用将用级联外键声明，因此查找表中的更改也会自动更新引用表

当然，规范化规则并不强制使用伪密钥，这些规则并没有提及伪密钥

---

回复您的注释：伪密钥，或，是用于标识行的“id”列。通常，通过自动递增分配值

ID  | typeID | categoryID | typeName
=====================================
1   |  1     |    1       | Gloves
2   |  2     |    1       | Bats
3   |  3     |    2       | Shoes
4   |  4     |    2       | Footballs

ID  | categoryID | catName
=============================
1   |  1         | Baseball Equipment
2   |  2         | Football Equipment

 create table product_hierarchy(
    id integer primary key,
    name character,
    parent_id references product_hierarchy)

client | product        | customURL
===================================
Smith  | Rawlings Glove | 1111
Smith  | Product 2      | 2222
Smith  | Product 3      | 3333
Smith  | Product 4      | 4444
Jones  | Rawlings Glove | 5555
Jones  | Product 4      | 6666

product        | type
=======================
Rawlings Glove | Gloves
Product 2      | Bats
Product 3      | Bats
Product 4      | Shoes

type      | category
==============================
Gloves    | Baseball Equipment
Bats      | Baseball Equipment
Shoes     | Football Equipment
Footballs | Football Equipment

category
==================
Baseball Equipment
Football Equipment