Django 模型 - 选择与外键？答案

【问题标题】：Django Model - choices versus foreign key?Django 模型 - 选择与外键？
【发布时间】：2010-10-26 06:06:58
【问题描述】：

我了解在 Django 中，ORM 不支持 MySQL 或 PostgreSQL 中的 ENUM 类型，因为这最初是 MySQL 扩展，不能跨其他 DB 类型移植。因此，这两个选项是对模型使用“选择”参数，或者使用外键引用。

这些方法的优缺点是什么？

对于像性别这样的东西，我假设你会使用“选择”，例如：

GENDER_CHOICES = (
    ('M', 'Male'),
    ('F', 'Female'),
)
...
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)

但是，对于诸如州名之类的内容，支持和反对使用单独的表以及该表的外键的原因是什么？

state = models.ForeignKey(AustralianState)

在什么情况下你会使用其中一种与另一种？

干杯，维克多

【问题讨论】：

标签： django django-models

【解决方案1】：

当潜在选择的数量很大时，您还应该考虑外键。这是考虑将 FK 用于国家或州的原因之一。否则，您实际上是在源代码中硬编码大量数据。

【讨论】：

这是出于性能原因吗？嗯，所以对于大量的状态，我想 FK 查找表是要走的路吗？然后你只需列出 Django 固定装置中的状态？
这不是性能方面的原因——除非你正在查看超过几千个选项，否则元组的性能可能会更好——这主要是一个维护问题。实际上，我相信 Django 在语言环境下内置了很多国家/地区字段。而且我想您可以创建一个 StateField 并将其导入其他文件。完全披露：我很确定我在部分应用程序中使用的国家和州字段实际上确实使用了选项。但 FK 也是一个不错的选择。
我要补充一点，在这种情况下，使用国家和州的缩写作为外键，而不是递增的整数，更有意义。

【解决方案2】：

我会使用不会随着时间而改变的选择。如果他们愿意，带有新模型的 FK 会更好。

【讨论】：

【解决方案3】：

我建议默认使用查找表，否则您将在代码中维护数据。它还使直接访问数据库的用户可以访问查找值，而不是通过您的应用程序（例如 BI/报告功能）。

一个值得注意的例外——我将使用选择而不是查找表——是一个查找实体，它具有控制代码级逻辑的值。您经常会在“状态”或“类型”实体（例如 BillingType）中找到它，其中逻辑取决于“类型”字段的值。在这些情况下，代码通常引用这些类型的显式标识符（代码），而添加新类型无论如何都需要更改逻辑（在代码中）。

【讨论】：