mysql - 如何在 PHP 中使用外键

Question

所以我了解如何创建外键并且我知道 FK 的目的是什么。但是我在理解如何使用它们时遇到了问题。我问了一个关于外键的问题 HERE(Click link)

这是我做的:

CREATE TABLE user(
  id INT(11) NOT NULL AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL,
  password VARCHAR(20) NOT NULL,
  PRIMARY KEY (id)
);

CREATE TABLE items(
  i_id INT(11) NOT NULL AUTO_INCREMENT,
  name TINYTEXT NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (i_id)
);

CREATE TABLE user_purchase(
  i_id INT(11) NOT NULL,
  name TINYTEXT NOT NULL,
  id INT(11) NOT NULL,
  FOREIGN KEY (i_id) REFERENCES items(i_id),
  FOREIGN KEY (name) REFERENCES items(name),
  FOREIGN KEY (id) REFERENCES user(id)
);

现在我的问题是如何使用 PHP 充分利用这一点？从上面的链接，人们建议在 user_purchase 表中只使用一个外键是好的，但是如果我想要多列怎么办？为什么我们不对同一个表的不同列使用多个外键？

我正在使用 mysql 和 php。如果您能展示一些示例，说明如何将 PHP 与具有外键的表一起使用以使用 MYSQL 命令获取信息，我将不胜感激。我真的需要一个彻底的解释。

我还需要了解规范化和非规范化这两个术语。如果您能提供一些链接，通过示例详细解释这些术语，或者如果您对一些适合数据库设计、实现等初学者的好书有任何建议，我将不胜感激。

非常感谢。

Answer 1

外键列/约束消歧

So I understand how to create foreign keys and I know what is the purpose of the FK. But I have a problem in understanding How to use them.

假设您指的是 外键约束 ，简短的回答是你只是不使用它们。

来了一个长的:

我们习惯于将列称为其他表的外键。特别是在规范化过程中，像“ user_purchase.i_id 是 items 表的外键”这样的短语会很常见。虽然这是描述关系的一种完全有效的方式，但当我们到达实现阶段时，它可能会变得有点模糊。

假设您创建的表没有 FOREIGN KEY条款:

CREATE TABLE user(
  id INT(11) NOT NULL AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL,
  password VARCHAR(20) NOT NULL,
  PRIMARY KEY (id)
);

CREATE TABLE items(
  i_id INT(11) NOT NULL AUTO_INCREMENT,
  name TINYTEXT NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (i_id)
);

CREATE TABLE user_purchase(
  i_id INT(11) NOT NULL,
  name TINYTEXT NOT NULL,
  id INT(11) NOT NULL,
);

请注意，在关系方面，仍然实现了外键列。有一列引用了 user表( id )和另一个引用 items 的表表 ( i_id ) -- 让我们把 name柱子放在一边。考虑以下数据:

  user              user_purchase    items
| id  username |    | id  i_id |    | i_id  name            price |
| 23  john     |    | 55   10  |    |  10   chocolate bar    3.42 |
| 55  mary     |    | 70   10  |    |  33   mobile phone    82.11 |
| 70  fred     |    | 70   33  |    |  54   toothpaste       8.67 |
                    | 55   10  |    |  26   toy car          6.00 |
                    | 70   26  |

关系就在那里。它是通过 user_purchase 实现的表，其中包含有关谁买了什么的信息。如果我们要查询数据库以获取相关报告，我们会这样做:

select * from user_purchase p
join user u on (p.id=u.id)
join items i on (p.i_id=i.i_id)

这就是我们如何使用关系和涉及的外键列。

现在，如果我们这样做:

insert into user_purchase (id,i_id) values (23,99)

显然，这是一个无效的条目。虽然有用户 id=23 , 没有带有 i_id=99 的项目. RDBMS 将允许这种情况发生，因为它不知道更好。然而。

这就是外键约束发挥作用的地方。通过指定 FOREIGN KEY (i_id) REFERENCES items(i_id)在 user_purchase表定义，我们本质上给了 RDBMS 一个要遵循的规则:带有 i_id 的条目未包含在 items.i_id 中的值列是 Not Acceptable 。换句话说， 当外键列实现引用时，外键约束强制执行引用完整性 .

但是请注意，上面的 select不会改变，只是因为您定义了 FK 约束。因此，您不使用 FK 约束，RDBMS 会使用，以保护您的数据。

冗余

...what if I want several columns? Why don't we use several foreign keys for different columns of the same table?

问问自己:你为什么想要那个？如果两个外键用于相同的目的，冗余最终会给您带来麻烦。考虑以下数据:

 user_purchase                   items
| id  i_id  name           |    | i_id  name            price |
| 55   10   chocolate bar  |    |  10   chocolate bar    3.42 |
| 70   10   chocolate bar  |    |  33   mobile phone    82.11 |
| 70   33   mobile phone   |    |  54   toothpaste       8.67 |
| 55   10   toothpaste     |    |  26   toy car          6.00 |
| 70   26   toy car        |

这张图有什么问题？用户是否 55买两根巧克力棒，还是一根巧克力棒和一根牙膏？这种歧义会导致大量的努力来保持数据同步，如果我们只保留一个外键，这将是不必要的。事实上，为什么不放弃 name完全列，因为它是由关系隐含的。

当然，我们可以通过设置 PRIMARY KEY(i_id,name) 来实现复合外键来解决这个问题。为 items表(或定义一个额外的 UNIQUE(i_id,name) 索引，这并不重要)然后设置一个 FOREIGN KEY(i_id,name) REFERENCES items(i_id,name) .这样，只有 (i_id,name) 对存在于 items 中。表对 user_purchases 有效.除了您仍然拥有 的事实之外一 外键，这种方法完全没有必要，前提是 i_id列已经足以识别一个项目(不能对 name 列说同样的话......)。

但是，并没有禁止在表中使用多个外键的规则。事实上，有些情况需要这种方法。考虑一个 person(id,name)表和一个 parent(person,father,mother)一，有以下数据:

 person             parent
| id  name    |    | person  father  mother |
| 14  John    |    |   21      14      59   |
| 43  Jane    |    |   14      76      43   |
| 21  Mike    |
| 76  Frank   |
| 59  Mary    |

显然， parent 的所有三列表是 person 的外键.但是，不是针对同一个关系，而是针对三个不同的关系:由于一个人的 parent 也是人，因此两个对应的列必须引用同一个表 person做。但是请注意，这三个字段不仅可以而且还必须引用不同的 person s 在同一个 parent排，因为没有人是他自己的 parent ，也没有人的父亲是他的母亲。