Question

所以我继承了一些django。

mySQL表很简单，其中parent不是FK关系，只是“Parent”id：

CREATE TABLE `Child` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `parent` int(10) unsigned NOT NULL,
  `name` varchar(255) NOT NULL,
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=24;

然后发起人做了这个......

class Child(models.Model):
    """Project Child information"""
    id = models.AutoField(primary_key=True)
    parent = models.ForeignKey(Parent)
    name = models.CharField(max_length=255)

    class Meta:
        managed = False

不可否认，我不是SQL Jockey，但我知道“真正的”外键关系看起来与此通知类似CONSTRAINT ...

CREATE TABLE `Child` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(11) NOT NULL,
  `name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  KEY `child_63f17a16` (`parent_id`),
  CONSTRAINT `parent_id_refs_id_34923e1e` FOREIGN KEY (`parent_id`) REFERENCES `Parent` (`id`)
) ENGINE=InnoDB;

我想知道的是：

我可以期待通过这种“诡计”看到什么问题。
虽然这似乎有效 - 建议还是建议。
我们是否会建议将SQL修改为add in the constraint？

非常感谢！

Answer 1

没有实际约束可能会导致参考文献被破坏，父母无效以及其他类型的数据不一致。我不是Django的专家，但我敢猜测，在大多数情况下，除非你故意添加一些无效记录，否则Django仍会处理关系。
通常情况下，如果你的RDBMS支持外键约束，那么绝对没有理由不使用它们，并且它可能被认为是一个忽略它们的设计缺陷。
您应该考虑添加关键约束。它们不仅可以让您的DBMS更好地了解如何优化查询，还可以确保数据的一致性。我非常确定Django在某个地方设置了一个自动生成SQL以在运行manage.py syncdb时添加关键约束

有关您为什么更喜欢外键的更多信息，请阅读MySQL Foreign Key Documentation

最有趣的是：

InnoDB需要外键和引用键的索引，以便外键检查速度快，不需要进行表扫描。在引用表中，必须有一个索引，其中外键列以相同的顺序列为第一列。如果引用表不存在，则会自动在引用表上创建此索引。（这与某些旧版本形成对比，在旧版本中，必须显式创建索引，否则外键约束的创建将失败。）如果给定，则使用index_name，如前所述。

Answer 2

它应该更快......因为你在子表中添加行之前没有检查约束。但是使用外键，它可以使您的生活更轻松，因为您可以使用更新和删除。我会选择约束。

理解/ mySQL也是在Django中欺骗ForeignKey关系

2 个答案: