Question

我之前知道这样的问题。我确保它们具有相同的数据类型并检查了我的语法，但我仍然收到错误：

 ALTER TABLE meetings ADD FOREIGN KEY (ownerName) REFERENCES employees(name);

ERROR 1215（HY000）：无法添加外键约束

mysql> desc `meetings`;
    +-----------+-------------+------+-----+---------+----------------+
    | Field     | Type        | Null | Key | Default | Extra          |
    +-----------+-------------+------+-----+---------+----------------+
    | id        | int(11)     | NO   | PRI | NULL    | auto_increment |
    | room      | int(6)      | NO   |     | NULL    |                |
    | ownerName | varchar(30) | NO   |     | NULL    |                |
    | ownerID   | varchar(30) | NO   |     | NULL    |                |
    +-----------+-------------+------+-----+---------+----------------+
    4 rows in set (0.00 sec)

    mysql> desc `employees`;
    +----------+--------------+------+-----+---------+-------+
    | Field    | Type         | Null | Key | Default | Extra |
    +----------+--------------+------+-----+---------+-------+
    | name     | varchar(30)  | NO   |     | NULL    |       |
    | username | varchar(30)  | NO   | PRI | NULL    |       |
    | pswd     | varchar(255) | YES  |     | NULL    |       |
    +----------+--------------+------+-----+---------+-------+

我做错了什么？

Answer 1

更改＆＃39;员工的主键＆＃39;从用户名到名称。然后你可以使用

ALTER TABLE meetings ADD FOREIGN KEY (ownerName) REFERENCES employees(name);

Answer 2

我做错了什么？错误1215可能是此处最少的问题。

针对此问题给出的一些答案建议username中employees引用的列而不是name，这样就可以了，但忽略了一些真正的根本问题在架构中很可能不是海报对这些列的意图。这个答案的其余部分是基于我自己的假设。

会议表

查看meetings表，我想知道ownerID列的用途。由于目的是将ownerName作为employees的外键，究竟是什么ownerID？该名称表明它也以某种方式引用employees，但id中没有ownerID或employees。此外，如果任何列起始所有者...指的是员工，那么为什么在meetings表中都需要两者？其中一个肯定是多余的。为什么ownerID是VARCHAR（30）？ ID列往往是INT。当然，我可能会对此进行大量阅读，ownerID可能还有一些与员工无关的其他目的，但如果是这样的话，该名称可能会在将来引起混淆。

meetings表在id中也有一个INT代理键。 room还有另一个INT。由于room不是外键，它表明房间要么始终只用数字来识别（这在我的经验中会很奇怪），并且没有什么比值得捕获的“房间”（例如位置），容量，设备等）在单独的表中打扰关于房间的建模数据（再次不太可能）。或者，room本身可能是引用尚未定义的id表中的INT rooms列的外键。

员工表

如果我们接受ownerID作为拥有会议的员工的更合适的外键（它使用的内存少于name或{{1}的内存然后，一致性会建议另一个代理键username作为id表中的主键。这样做不是必要，employees将是独一无二的，并且它本身就很好，但它更简单，更有效。另一个建议是username应该是name中的PK是错误的 - 它预先假定名称始终是唯一的。

用于涵盖员工姓名的单一列也不常见。

关于引用PK或唯一索引的观点很好（即使在Innodb中不是绝对必要的），我只是说employees是错误的外键而ownerName并且username是错误的引用，因为有更好的选择。

最后，是一个空密码（name）是一个好主意吗？

MySQL添加外键错误1215

2 个答案: