模型P

模型准确且唯一的描述了数据。它包含您储存的数据的重要字段和行为。一般来说，每一个模型都映射一张数据库表。

基础：

每个模型都是一个 Python 的类，这些类继承 django.db.models.Model
模型类的每个属性都相当于一个数据库的字段。
利用这些，Django 提供了一个自动生成访问数据库的 API；请参阅执行查询。

快速上手P

这个样例定义了一个 Person 模型，拥有 first_name 和 last_name:

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

first_name 和 last_name 是模型的字段。每个字段都被指定为一个类属性，并且每个属性映射为一个数据库列。

上面的 Person 模型会创建一个如下的数据库表：

CREATE TABLE myapp_person (
    "id" serial NOT NULL PRIMARY KEY,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL
);

一些技术上的说明：

该表的名称 myapp_person 是自动从某些模型元数据中派生出来，但可以被改写。参阅 Table names 获取更多信息。
一个 id 字段会被自动添加，但是这种行为可以被改写。请参阅自动设置主键。
本例子中 创建数据表 的语法是 PostgreSQL 格式的。值得注意的是，Django 依据你在配置文件中指定的数据库后端生成对应的 SQL 语句。

使用模型P

一旦你定义了你的模型，你需要告诉 Django 你准备使用这些模型。你需要修改设置文件中的 INSTALLED_APPS ，在这个设置中添加包含 models.py 文件的模块名称。

例如，若模型位于项目中的 myapp.models 模块（此包结构由 manage.py startapp 命令创建）， INSTALLED_APPS 应设置如下：

INSTALLED_APPS = [
    #...
    'myapp',
    #...
]

当你向 INSTALLED_APPS 添加新的应用的时候，请务必运行 manage.py migrate，此外你也可以先使用以下命令进行迁移 manage.py makemigrations。

字段P

模型中最重要且唯一必要的是数据库的字段定义。字段在类属性中定义。定义字段名时应小心避免使用与模型 API 冲突的名称，如 clean, save, or delete 等.

举例：

from django.db import models

class Musician(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    instrument = models.CharField(max_length=100)

class Album(models.Model):
    artist = models.ForeignKey(Musician, on_delete=models.CASCADE)
    name = models.CharField(max_length=100)
    release_date = models.DateField()
    num_stars = models.IntegerField()

字段类型P

模型中每一个字段都应该是某个 Field 类的实例， Django 利用这些字段类来实现以下功能：

字段类型用以指定数据库数据类型（如：INTEGER, VARCHAR, TEXT）。
在渲染表单字段时默认使用的 HTML 视图 (如： <input type="text">, <select>)。
基本的有效性验证功能，用于 Django 后台和自动生成的表单。

Django 内置了数十种字段类型；你可以在模型字段参考中看到完整列表。如果 Django 内置类型不能满足你的需求，你可以很轻松地编写自定义的字段类型；参见编写自定义模型字段(model fields)。

字段选项P

每一种字段都需要指定一些特定的参数（参考模型字段）。例如， CharField （以及它的子类）需要接收一个 max_length 参数，用以指定数据库存储 VARCHAR 数据时用的字节数。

一些可选的参数是通用的，可以用于任何字段类型，详情请见参考，下面介绍一部分经常用到的通用参数：

null

如果设置为 True，当该字段为空时，Django 会将数据库中该字段设置为 NULL。默认为 False 。

blank

如果设置为 True，该字段允许为空。默认为 False。

注意该选项与 False 不同， null 选项仅仅是数据库层面的设置，然而 blank 是涉及表单验证方面。如果一个字段设置为 blank=True ，在进行表单验证时，接收的数据该字段值允许为空，而设置为 blank=False 时，不允许为空。

choices

一系列二元组，用作此字段的选项。如果提供了二元组，默认表单小部件是一个选择框，而不是标准文本字段，并将限制给出的选项。

一个选项列表：

YEAR_IN_SCHOOL_CHOICES = [
    ('FR', 'Freshman'),
    ('SO', 'Sophomore'),
    ('JR', 'Junior'),
    ('SR', 'Senior'),
    ('GR', 'Graduate'),
]

注解

每当 choices 的顺序变动时将会创建新的迁移。

每个二元组的第一个值会储存在数据库中，而第二个值将只会用于在表单中显示。

对于一个模型实例，要获取该字段二元组中相对应的第二个值，使用 get_FOO_display() 方法。例如：

from django.db import models

class Person(models.Model):
    SHIRT_SIZES = (
        ('S', 'Small'),
        ('M', 'Medium'),
        ('L', 'Large'),
    )
    name = models.CharField(max_length=60)
    shirt_size = models.CharField(max_length=1, choices=SHIRT_SIZES)

>>> p = Person(name="Fred Flintstone", shirt_size="L")
>>> p.save()
>>> p.shirt_size
'L'
>>> p.get_shirt_size_display()
'Large'

default

该字段的默认值。可以是一个值或者是个可调用的对象，如果是个可调用对象，每次实例化模型时都会调用该对象。

help_text

额外的“帮助”文本，随表单控件一同显示。即便你的字段未用于表单，它对于生成文档也是很有用的。

primary_key

如果设置为 True ，将该字段设置为该模型的主键。

在一个模型中，如果你没有对任何一个字段设置 primary_key=True 选项。 Django 会自动添加一个 IntegerField 字段，并设置为主键，因此除非你想重写 Django 默认的主键设置行为，你可以不手动设置主键。详情请见自动设置主键。

主键字段是只可读的，如果你修改一个模型实例的主键并保存，这等同于创建了一个新的模型实例。例如：

from django.db import models

class Fruit(models.Model):
    name = models.CharField(max_length=100, primary_key=True)

>>> fruit = Fruit.objects.create(name='Apple')
>>> fruit.name = 'Pear'
>>> fruit.save()
>>> Fruit.objects.values_list('name', flat=True)
<QuerySet ['Apple', 'Pear']>

unique

如果设置为 True，这个字段的值必须在整个表中保持唯一。

再次声明，以上只是一些通用参数的简略描述。你可以在通用可选参数参考中找到完整的介绍。

自动设置主键P

默认情况下， Django 会给每一个模型添加下面的字段：

id = models.AutoField(primary_key=True)

这是一个自增的主键。

如果你想自己指定主键，在你想要设置为主键的字段上设置参数 primary_key=True。如果 Django 看到你显式地设置了 Field.primary_key，将不会自动在表（模型）中添加 id 列。

每个模型都需要拥有一个设置了 primary_key=True 的字段（无论是显式的设置还是 Django 自动设置）。

字段备注名P

除了 ForeignKey， ManyToManyField 和 OneToOneField，任何字段类型都接收一个可选的位置参数 verbose_name，如果未指定该参数值， Django 会自动使用字段的属性名作为该参数值，并且把下划线转换为空格。

在该例中：备注名为 "person's first name":

first_name = models.CharField("person's first name", max_length=30)

在该例中：备注名为 "first name":

first_name = models.CharField(max_length=30)

ForeignKey, ManyToManyField and OneToOneField 接收的第一个参数为模型的类名，后面可以添加一个 verbose_name 参数：

poll = models.ForeignKey(
    Poll,
    on_delete=models.CASCADE,
    verbose_name="the related poll",
)
sites = models.ManyToManyField(Site, verbose_name="list of sites")
place = models.OneToOneField(
    Place,
    on_delete=models.CASCADE,
    verbose_name="related place",
)

惯例是不将 verbose_name 的首字母大写，必要时 Djanog 会自动把首字母转换为大写。

关联关系P

显然，关系型数据库的强大之处在于各表之间的关联关系。 Django 提供了定义三种最常见的数据库关联关系的方法：多对一，多对多，一对一。

多对一关联P

定义一个多对一的关联关系，使用 django.db.models.ForeignKey 类。就和其它 Field 字段类型一样，只需要在你模型中添加一个值为该类的属性。

ForeignKey 类需要添加一个位置参数，即你想要关联的模型类名。

例如，如果一个 Car 模型有一个制造者 Manufacturer --就是说一个 Manufacturer 制造许多辆车，但是每辆车都仅有一个制造者-- 那么使用下面的方法定义这个关系：

from django.db import models

class Manufacturer(models.Model):
    # ...
    pass

class Car(models.Model):
    manufacturer = models.ForeignKey(Manufacturer, on_delete=models.CASCADE)
    # ...

你也可以创建自关联关系（一个模型与它本身有多对一的关系）和与未定义的模型间的关联关系；详情请见模型字段参考。

建议设置 ForeignKey 字段名（上例中的 manufacturer ）为想要关联的模型名，但是你也可以随意设置为你想要的名称，例如：

class Car(models.Model):
    company_that_makes_it = models.ForeignKey(
        Manufacturer,
        on_delete=models.CASCADE,
    )
    # ...

参见

ForeignKey 字段还可以接收一些其他的参数，详见模型字段参考，这些可选的参数可以更深入的规定关联关系的具体实现。

关于反向关联对象的细节，参见反向关联例子。

如要查看相关示例代码，详见模型多对一关联实例。

多对多关联P

定义一个多对多的关联关系，使用 django.db.models.ManyToManyField 类。就和其他 Field 字段类型一样，只需要在你模型中添加一个值为该类的属性。

ManyToManyField 类需要添加一个位置参数，即你想要关联的模型类名。

例如：如果 Pizza 含有多种 Topping （配料） -- 也就是一种 Topping 可能存在于多个 Pizza 中，并且每个 Pizza 含有多种 Topping --那么可以这样表示这种关系：

from django.db import models

class Topping(models.Model):
    # ...
    pass

class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)

和 ForeignKey 类一样，你也可以创建自关联关系（一个对象与他本身有着多对多的关系）和与未定义的模型的关系。

建议设置 ManyToManyField 字段名（上例中的 toppings ）为一个复数名词，表示所要光联的模型对象的集合。

对于多对多光联关系的两个模型，可以在任何一个模型中添加 ManyToManyField 字段，但只能选择一个模型设置该字段，即不能同时在两模型中添加该字段。

一般来讲，应该把 ManyToManyField 实例放到需要在表单中被编辑的对象中。在之前的例子中， toppings 被放在 Pizza 当中（而不是 Topping 中有指向 pizzas 的 ManyToManyField 实例）因为相较于配料被放在不同的披萨当中，披萨当中有很多种配料更加符合常理。按照先前说的，在编辑 Pizza 的表单时用户可以选择多种配料。

参见

如要查看完整示例代码，详见模型多对多关联实例。

ManyToManyField 字段也接受一些模型字段参考中介绍的参数。这些可选的参数可以更深入地规定关联关系的具体实现。

在多对多(many-to-many)关系中添加添加额外的属性字段P

如果你只是想要一个类似于记录披萨和配料之间混合和搭配的简单多对多关系，标准的 ManyToManyField 就足够你用了。然而，有的时候你可能会需要在两个模型的关系中记录更多的数据。

举例来讲，考虑一个需要跟踪音乐人属于哪个音乐组的应用程序。在人和他们所在的组之间有一个多对多关系，你可以使用 ManyToManyField 来代表这个关系。然而，你想要记录更多的信息在这样的关联关系当中，比如你想要记录某人是何时加入一个组的。

对于这些情况，Django 允许你指定用于控制多对多关系的模型。你可以在中间模型当中添加额外的字段。在实例化 ManyToManyField 的时候使用 through 参数指定多对多关系使用哪个中间模型。对于我们举的音乐家的例子，代码如下：

from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=128)

    def __str__(self):
        return self.name

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, through='Membership')

    def __str__(self):
        return self.name

class Membership(models.Model):
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64)

你需要在设置中间模型的时候，显式地为多对多关系中涉及的中间模型指定外键。这种显式声明定义了这两个模型之间是如何关联的。

在中间模型当中有一些限制条件：

你的中间模型要么有且仅有一个指向源模型（我们例子当中的 Group ）的外键，要么你必须通过 ManyToManyField.through_fields 参数在多个外键当中手动选择一个外键，如果有多个外健且没有用 through_fields 参数选择一个的话，会出现验证错误。对于指向目标模型（我们例子当中的 Person ）的外键也有同样的限制。
在一个用于描述模型当中自己指向自己的多对多关系的中间模型当中，可以有两个指向同一个模型的外健，但这两个外健分表代表多对多关系（不同）的两端。如果外健的个数超过两个，你必须和上面一样指定 through_fields 参数，要不然会出现验证错误。
在定义模型自己指向自己的多对多关系时，如果使用中间模型，你必须定义 symmetrical=False （查看木星字段参考）。

现在你已经通过中间模型完成你的 ManyToManyField （例子中的 Membership ），可以开始创建一些多对多关系了。你通过实例化中间模型来创建关系：

>>> ringo = Person.objects.create(name="Ringo Starr")
>>> paul = Person.objects.create(name="Paul McCartney")
>>> beatles = Group.objects.create(name="The Beatles")
>>> m1 = Membership(person=ringo, group=beatles,
...     date_joined=date(1962, 8, 16),
...     invite_reason="Needed a new drummer.")
>>> m1.save()
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>]>
>>> ringo.group_set.all()
<QuerySet [<Group: The Beatles>]>
>>> m2 = Membership.objects.create(person=paul, group=beatles,
...     date_joined=date(1960, 8, 1),
...     invite_reason="Wanted to form a band.")
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>]>

你也可以使用 add(), create(), 或 set() 创建关系，只要你为任何必需的字段指定 through_defaults ：

>>> beatles.members.add(john, through_defaults={'date_joined': date(1960, 8, 1)})
>>> beatles.members.create(name="George Harrison", through_defaults={'date_joined': date(1960, 8, 1)})
>>> beatles.members.set([john, paul, ringo, george], through_defaults={'date_joined': date(1960, 8, 1)})

你可能更倾向直接创建中间模型。

如果自定义中间模型没有强制 (model1, model2) 对的唯一性，调用 remove() 方法会删除所有中间模型的实例：

>>> Membership.objects.create(person=ringo, group=beatles,
...     date_joined=date(1968, 9, 4),
...     invite_reason="You've been gone for a month and we miss you.")
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>, <Person: Ringo Starr>]>
>>> # This deletes both of the intermediate model instances for Ringo Starr
>>> beatles.members.remove(ringo)
>>> beatles.members.all()
<QuerySet [<Person: Paul McCartney>]>

方法 clear() 用于实例的所有多对多关系：

>>> # Beatles have broken up
>>> beatles.members.clear()
>>> # Note that this deletes the intermediate model instances
>>> Membership.objects.all()
<QuerySet []>

一旦你建立了自定义多对多关联关系，就可以执行查询操作。和一般的多对多关联关系一样，你可以使用多对多关联模型的属性来查询：

# Find all the groups with a member whose name starts with 'Paul'
>>> Group.objects.filter(members__name__startswith='Paul')
<QuerySet [<Group: The Beatles>]>

当你使用中间模型的时候，你也可以查询他的属性：

# Find all the members of the Beatles that joined after 1 Jan 1961
>>> Person.objects.filter(
...     group__name='The Beatles',
...     membership__date_joined__gt=date(1961,1,1))
<QuerySet [<Person: Ringo Starr]>

如果你想访问一个关系的信息时你可以直接查询 Membership 模型：

>>> ringos_membership = Membership.objects.get(group=beatles, person=ringo)
>>> ringos_membership.date_joined
datetime.date(1962, 8, 16)
>>> ringos_membership.invite_reason
'Needed a new drummer.'

另一种访问同样信息的方法是通过 Person 对象来查询多对多递归关联关系：

>>> ringos_membership = ringo.membership_set.get(group=beatles)
>>> ringos_membership.date_joined
datetime.date(1962, 8, 16)
>>> ringos_membership.invite_reason
'Needed a new drummer.'

一对一关联P

使用 OneToOneField 来定义一对一关系。就像使用其他类型的 Field 一样：在模型属性中包含它。

当一个对象以某种方式“继承”另一个对象时，这对该对象的主键非常有用。

OneToOneField 需要一个位置参数：与模型相关的类。

例如，当你要建立一个有关“位置”信息的数据库时，你可能会包含通常的地址，电话等字段。接着，如果你想接着建立一个关于关于餐厅的数据库，除了将位置数据库当中的字段复制到 Restaurant 模型，你也可以将一个指向 Place OneToOneField 放到 Restaurant 当中（因为餐厅“是一个”地点）；事实上，在处理这样的情况时最好使用模型继承，它隐含的包括了一个一对一关系。

和 ForeignKey 一样，可以创建自关联关系也可以创建与尚未定义的模型的关系。

参见

点击文档一对一关联模型实例来查看完整的例子。

OneToOneField 字段还接受一个可选的 parent_link 参数。

OneToOneField 类通常自动的成为模型的主键，这条规则现在不再使用了（然而你可以手动指定 primary_key 参数）。因此，现在可以在单个模型当中指定多个 OneToOneField 字段。

跨文件模型P

关联另一个应用中的模型是当然可以的。为了实现这一点，在定义模型的文件开头导入需要被关联的模型。接着就可以在其他有需要的模型类当中关联它了。比如：

from django.db import models
from geography.models import ZipCode

class Restaurant(models.Model):
    # ...
    zip_code = models.ForeignKey(
        ZipCode,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )

字段命名限制P

Django 对模型的字段名有一些限制：

一个字段的名称不能是 Python 保留字，因为这会导致 Python 语法错误。比如：

class Example(models.Model):
    pass = models.IntegerField() # 'pass' is a reserved word!

一个字段名称不能包含连续的多个下划线，原因在于 Django 查询语法的工作方式。比如：
```
class Example(models.Model):
    foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
```
字段名不能以下划线结尾，原因同上。

但是，这些限制是可以被解决的，因为字段名没要求和数据库列名一样。查看 db_column 选项。

SQL保留字，例如 join， where 或 select，是可以被用在模型字段名当中的，因为 Django 在对底层的 SQL 查询当中清洗了所有的数据库表名和字段名，通过使用特定数据库引擎的引用语法。

自定义的字段类型P

如果已经存在的模型字段不能满足你的需求，或者你希望支持一些不太常见的数据库列类型，你可以创建自己的字段类。在编写自定义模型字段(model fields) 中提供了创建自定义字段的各方面内容。

`Meta` 选项P

使用内部 Meta类 来给模型赋予元数据，就像：

from django.db import models

class Ox(models.Model):
    horn_length = models.IntegerField()

    class Meta:
        ordering = ["horn_length"]
        verbose_name_plural = "oxen"

模型的元数据即“所有不是字段的东西”，比如排序选项（ ordering ），数据库表名（ db_table ），或是阅读友好的单复数名（ verbose_name 和 verbose_name_plural ）。这些都不是必须的，并且在模型当中添加 Meta类 也完全是可选的。

在模型可选参数参考中列出了 Meta 可使用的全部选项。

模型属性P

objects: 模型当中最重要的属性是 Manager。它是 Django 模型和数据库查询操作之间的接口，并且它被用作从数据库当中获取实例，如果没有指定自定义的 Manager 默认名称是 objects。Manager 只能通过模型类来访问，不能通过模型实例来访问。

模型方法P

在模型中添加自定义方法会给你的对象提供自定义的“行级”操作能力。与之对应的是类 Manager 的方法意在提供“表级”的操作，模型方法应该在某个对象实例上生效。

这是一个将相关逻辑代码放在一个地方的技巧——模型。

比如，该模型有一些自定义方法：

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    birth_date = models.DateField()

    def baby_boomer_status(self):
        "Returns the person's baby-boomer status."
        import datetime
        if self.birth_date < datetime.date(1945, 8, 1):
            return "Pre-boomer"
        elif self.birth_date < datetime.date(1965, 1, 1):
            return "Baby boomer"
        else:
            return "Post-boomer"

    @property
    def full_name(self):
        "Returns the person's full name."
        return '%s %s' % (self.first_name, self.last_name)

例子中最后一个方法是 property。

文档模型实例参考包含了自动提供给每个模型的方法的完整列表。你可以复写大部分的方法，参考下面的 overriding predefined model methods ——下面介绍两个你最可能期望复写的：

__str__()

一个 Python 的“魔法方法”，返回值友好地展示了一个对象。Python 和 Django 在要将模型实例展示为纯文本时调用。最有可能的应用场景是交互式控制台或后台。

你将会经常定义此方法；默认提供的不是很好用。

get_absolute_url()

该方法告诉 Django 如何计算一个对象的 URL。Django 在后台接口使用此方法，或任意时间它需要计算一个对象的 URL。

任何需要一个唯一 URL 的对象需要定义此方法。

重写之前定义的模型方法P

还有一个模型方法的集合，包含了一些你可能自定义的数据库行为。尤其是这两个你最有可能定制的方法 save() 和 delete()。

你可以随意地重写这些方法（或其它模型方法）来更改方法的行为。

一个典型的重写内置方法的场景是你想在保存对象时额外做些事。比如（查看文档 save() 了解其接受的参数）:

from django.db import models

class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def save(self, *args, **kwargs):
        do_something()
        super().save(*args, **kwargs)  # Call the "real" save() method.
        do_something_else()

你也可以阻止保存:

from django.db import models

class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def save(self, *args, **kwargs):
        if self.name == "Yoko Ono's blog":
            return # Yoko shall never have her own blog!
        else:
            super().save(*args, **kwargs)  # Call the "real" save() method.

调用父类的方法非常重要——这里指 super().save(*args, **kwargs) ——确保对象正确的写入数据库。若你忘记调用父类方法，默认行为不会被触发，数据库也不会被操作。

同时传递模型方法接受的参数也很重要—— *args, **kwargs 会接受这些参数。Django 会不时地扩展模型内置方法的功能，也会添加新参数。如果你在重写的方法中使用了 *args, **kwargs，这将确保你的方法能接受这些新加的参数。

重写的模型方法不会在批量操作中调用

注意，删除一个模型对象不总是要调用 delete() 方法。例如， ref:使用 QuerySet 批量删除对象 <topics-db-queries-delete> 和 级联删除。为了确保自定义的删除逻辑被执行，你可以使用 pre_delete 和 post_delete 信号。

不幸的是，批量 creating 和 updating 操作不支持上述操作，因为这两种操作未调用 save()，pre_save 和 post_save。

执行自定义 SQLP

另一个常见的模式是在模型方法和模块方法中编写自定义 SQL 语句。更多关于使用原生 SQL的细节，参见文档使用原生 SQL。

模型继承P

模型继承在 Django 中与普通类继承在 Python 中的工作方式几乎完全相同，但也仍应遵循本页开头的内容。这意味着其基类应该继承自 django.db.models.Model。

你只需要决定父类模型是否需要拥有它们的权利（拥有它们的数据表），或者父类仅作为承载仅子类中可见的公共信息的载体。

Django 有三种可用的集成风格。

常见情况下，你仅将父类用于子类公共信息的载体，因为你不会想在每个子类中把这些代码都敲一遍。这样的父类永远都不会单独使用，所以抽象基类是你需要的。
若你继承了一个模型（可能来源其它应用），且想要每个模型都有对应的数据表，客官这边请多表继承。
最后，若你只想修改模型的 Python 级行为，而不是以任何形式修改模型字段，代理模型会是你的菜。

抽象基类P

抽象基类在你要将公共信息放入很多模型时会很有用。编写你的基类，并在 Meta 类中填入 abstract=True。该模型将不会创建任何数据表。当其用作其它模型类的基类时，它的字段会自动添加至子类。

一个例子:

from django.db import models

class CommonInfo(models.Model):
    name = models.CharField(max_length=100)
    age = models.PositiveIntegerField()

    class Meta:
        abstract = True

class Student(CommonInfo):
    home_group = models.CharField(max_length=5)

Student 模型拥有3个字段： name， age 和 home_group。 CommonInfo 模型不能用作普通的 Django 模型，因为它是一个抽象基类。它不会生成数据表，也没有管理器，也不能被实例化和保存。

从抽象基类继承来的字段可被其它字段或值重写，或用 None 删除。

对很多用户来说，这种继承可能就是你想要的。它提供了一种在 Python 级抽出公共信息的方法，但仍会在子类模型中创建数据表。

`Meta` 继承P

当一个抽象基类被建立，Django 将所有你在基类中申明的 Meta 内部类以属性的形式提供。若子类未定义自己的 Meta 类，它会继承父类的 Meta。当然，子类也可继承父类的 Meta，比如:

from django.db import models

class CommonInfo(models.Model):
    # ...
    class Meta:
        abstract = True
        ordering = ['name']

class Student(CommonInfo):
    # ...
    class Meta(CommonInfo.Meta):
        db_table = 'student_info'

Django 在安装 Meta 属性前，对抽象基类的 Meta 做了一个调整——设置 abstract=False。这意味着抽象基类的子类不会自动地变成抽象类。当然，你可以继承一个抽象基类创建另一个抽象基类。你只需记住显示地设置 abstract=True。

抽象基类的某些 Meta 属性对子类是没用的。比如，包含 db_table 意味着所有的子类（你并未在子类中指定它们的 Meta）会使用同一张数据表，这肯定不是你想要的。

多表继承P

Django 支持的第二种模型继承方式是层次结构中的每个模型都是一个单独的模型。某个模型都指向分离的数据表，且可被独立查询和创建。继承关系介绍了子类和父类之间的连接（通过一个自动创建的 OneToOneField ）。比如:

from django.db import models

class Place(models.Model):
    name = models.CharField(max_length=50)
    address = models.CharField(max_length=80)

class Restaurant(Place):
    serves_hot_dogs = models.BooleanField(default=False)
    serves_pizza = models.BooleanField(default=False)

Place 的所有字段均在 Restaurant 中可用，虽然数据分别存在不同的表中。所有，以下操作均可:

>>> Place.objects.filter(name="Bob's Cafe")
>>> Restaurant.objects.filter(name="Bob's Cafe")

若有一个 Place 同时也是 Restaurant，你可以通过小写的模型名将 Place 对象转为 Restaurant 对象。

>>> p = Place.objects.get(id=12)
# If p is a Restaurant object, this will give the child class:
>>> p.restaurant
<Restaurant: ...>

然而，若上述例子中的 p 不是一个 Restaurant （它仅是个 Place 对象或是其它类的父类），指向 p.restaurant 会抛出一个 Restaurant.DoesNotExist 异常。

Restaurant 中自动创建的连接至 Place 的 OneToOneField 看起来像这样:

place_ptr = models.OneToOneField(
    Place, on_delete=models.CASCADE,
    parent_link=True,
)

你可以在 Restaurant 中重写该字段，通过申明你自己的 OneToOneField，并设置 parent_link=True。

`Meta` 和多表继承P

多表继承情况下，子类不会继承父类的 Meta。所以的 Meta 类选项已被应用至父类，在子类中再次应用会导致行为冲突（与抽象基类中应用场景对比，这种情况下，基类并不存在）。

故，子类模型无法访问父类的 Meta 类。不过，有限的几种情况下：若子类未指定 ordering 属性或 get_latest_by 属性，子类会从父类继承这些。

如果父类有排序，而你并不期望子类有排序，你可以显示的禁止它:

class ChildModel(ParentModel):
    # ...
    class Meta:
        # Remove parent's ordering effect
        ordering = []

继承与反向关系P

由于多表继承使用隐式的 OneToOneField 连接子类和父类，所以直接从父类访问子类是可能的，就像上述例子展示的那样。然而，使用的名字是 ForeignKey 和 ManyToManyField 关系的默认值。如果你在继承父类模型的子类中添加了这些关联，你必须指定 related_name 属性。假如你忘了，Django 会抛出一个合法性错误。

比如，让我们用上面的 Place 类创建另一个子类，包含一个 ManyToManyField:

class Supplier(Place):
    customers = models.ManyToManyField(Place)

这会导致以下错误:

Reverse query name for 'Supplier.customers' clashes with reverse query
name for 'Supplier.place_ptr'.

HINT: Add or change a related_name argument to the definition for
'Supplier.customers' or 'Supplier.place_ptr'.

将 related_name 像下面这样加至 customers 字段能解决此错误： models.ManyToManyField(Place, related_name='provider')。

指定父类连接字段P

如上所述，Django 会自动创建一个 OneToOneField ，将子类连接回非抽象的父类。如果你想修改连接回父类的属性名，你可以自己创建 OneToOneField，并设置 parent_link=True，表明该属性用于连接回父类。

代理模型P

使用多表继承时，每个子类模型都会创建一张新表。这一般是期望的行为，因为子类需要一个地方存储基类中不存在的额外数据字段。不过，有时候你只想修改模型的 Python 级行为——可能是修改默认管理器，或添加一个方法。

这是代理模型继承的目的：为原模型创建一个代理。你可以创建，删除和更新代理模型的实例，所以的数据都会存储的像你使用原模型（未代理的）一样。不同点是你可以修改代理默认的模型排序和默认管理器，而不需要修改原模型。

代理模型就像普通模型一样申明。你需要告诉 Django 这是一个代理模型，通过将 Meta 类的 proxy 属性设置为 True。

例如，假设你想为 Person 模型添加一个方法。你可以这么做:

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

class MyPerson(Person):
    class Meta:
        proxy = True

    def do_something(self):
        # ...
        pass

MyPerson 类与父类 Person 操作同一张数据表。特别提醒， Person 的实例能通过 MyPerson 访问，反之亦然。

>>> p = Person.objects.create(first_name="foobar")
>>> MyPerson.objects.get(first_name="foobar")
<MyPerson: foobar>

你也可以用代理模型定义模型的另一种不同的默认排序方法。你也许不期望总对 “Persion” 进行排序，但是在使用代理时，总是依据 “last_name” 属性进行排序。这很简单:

class OrderedPerson(Person):
    class Meta:
        ordering = ["last_name"]
        proxy = True

现在，普通的 Person 查询结果不会被排序，但 OrderdPerson 查询接轨会按 last_name 排序。

代理模型继承“Meta”属性和普通模型一样。

`QuerySet` 仍会返回请求的模型P

当你用 Person 对象查询时，Django 永远不会返回 MyPerson 对象。Person 对象的查询结果集总是返回对应类型。代理对象存在的全部意义是帮你复用原 Person 提供的代码和自定义的功能代码（并未依赖其它代码）。不存在什么方法能在你创建完代理后，帮你替换所有 Person （或其它）模型。

基类约束P

一个代理模型必须继承自一个非抽象模型类。你不能继承多个非抽象模型类，因为代理模型无法在不同数据表之间提供任何行间连接。一个代理模型可以继承任意数量的抽象模型类，假如他们没有定义任何的模型字段。一个代理模型也可以继承任意数量的代理模型，只需他们共享同一个非抽象父类。

代理模型管理器P

若你未在代理模型中指定模型管理器，它会从父类模型中继承。如果你在代理模型中指定了管理器，它会成为默认管理器，但父类中定义的管理器仍是可用的。

随着上面的例子一路走下来，你可以在查询 Person 模型时这样修改默认管理器:

from django.db import models

class NewManager(models.Manager):
    # ...
    pass

class MyPerson(Person):
    objects = NewManager()

    class Meta:
        proxy = True

若你在不替换已存在的默认管理器的情况下，为代理添加新管理器，你可以使用文档自定义管理器中介绍的技巧：创建一个包含新管理器的基类，在继承列表中，主类后追加这个基类:

# Create an abstract class for the new manager.
class ExtraManagers(models.Model):
    secondary = NewManager()

    class Meta:
        abstract = True

class MyPerson(Person, ExtraManagers):
    class Meta:
        proxy = True

通常情况下，你可能不需要这么做。然而，你需要的时候，这也是可以的。

代理继承和未托管的模型间的区别P

代理模型继承可能看起来和创建未托管的模型很类似，通过在模型的 Meta 类中定义 managed 属性。

通过小心地配置 Meta.db_table，你将创建一个未托管的模型，该模型将对现有模型进行阴影处理，并添加一些 Python 方法。然而，这会是个经常重复的且容易出错的过程，因为你要在做任何修改时保持两个副本的同步。

另一方面，代理模型意在表现的和所代理的模型一样。它们总是与父模型保持一致，因为它们直接从福利继承字段和管理器。

通用性规则：

当你克隆一个已存在模型或数据表时，并且不想要所以的原数据表列，配置 Meta.managed=False。这个选项在模型化未受 Django 控制的数据库视图和表格时很有用。
如果你只想修改模型的 Python 行为，并保留原有字段，配置 Meta.proxy=True。这个配置使得代理模型在保存数据时，确保数据结构和原模型的完全一样。

多重继承P

和 Python 中的继承一样，Django 模型也能继承自多个父类模型。请记住，Python 的命名规则这里也有效。第一个出现的基类（比如 Meta ）就是会被使用的那个；举个例子，如果存在多个父类包含 Meta，只有第一个会被使用，其它的都会被忽略。

一般来说，你并不会同时继承多个父类。常见的应用场景是 “混合” 类：为每个继承此类的添加额外的字段或方法。试着保持你的继承层级尽可能的简单和直接，这样未来你就不用为了确认某段信息是哪来的而拔你为数不多的头发了。

注意，继承自多个包含 id 主键的字段会抛出错误。正确的使用多继承，你可以在基类中显示使用 AutoField:

class Article(models.Model):
    article_id = models.AutoField(primary_key=True)
    ...

class Book(models.Model):
    book_id = models.AutoField(primary_key=True)
    ...

class BookReview(Book, Article):
    pass

或者在公共祖先中存储 AutoField。这会要求为每个父类模型和公共祖先使用显式的 OneToOneField ，避免与子类自动生成或继承的字段发生冲突:

class Piece(models.Model):
    pass

class Article(Piece):
    article_piece = models.OneToOneField(Piece, on_delete=models.CASCADE, parent_link=True)
    ...

class Book(Piece):
    book_piece = models.OneToOneField(Piece, on_delete=models.CASCADE, parent_link=True)
    ...

class BookReview(Book, Article):
    pass

不能用字段名 "hiding"P

在普通的 Python 类继承中，允许子类重写父类的任何属性。在 Django 中，针对模型字段在，这一般是不允许的。如果有个非抽象模型基类，拥有一个名为 author 字段，你可以任意继承自基类的类中创建另一个模型字段，或定义一个叫 author 的属性。

此规范不针对从抽象模型基类继承获得的字段。这些字段可被其它字段或值重写，也可以通过配置 field_name = None 删除。

警告

模型管理器是由抽象基类继承来的。重写由 Manager 指定的字段可能会导致精细的 bug。参见自定义管理器和模型继承。

注解

某些字段在模型内定义了额外的属性，比如，一个 ForeignKey 定义了一个额外属性，名称为字段名接 _id，并在外部模型中的添加 related_name 和 related_query_name。

这些额外属性不能被重写，除非定义该属性的字段被修改或删除，这样就不会定义额外属性了。

在父模型中重写字段会在很多方面造成困难，比如创建新实例（特指那些字段在 Model.__init__ 中初始化的那些）和序列化。这些特性，普通的 Python 类继承不需要用完全一样的方式处理，故此， Django 的模型继承和 Python 的类继承之间的区别不是随意的。

这些限制只针对那些是 Field 实例的属性。普通的 Python 属性可被随便重写。它还对 Python 能识别的属性生效：如果你同时在子类和多表继承的祖先类中指定了数据表的列名（它们是两张不同的数据表中的列）。

若你在祖先模型中重写了任何模型字段，Django 会抛出一个 FieldError。

在一个包中管理模型P

manage.py startapp 命令创建了一个应用结构，包含一个 models.py 文件。若你有很多木星，用独立的文件管理它们会很实用。

为了达到此目的，创建一个 models 包。删除 models.py，创建一个 myapp/models 目录，包含一个 __init__.py 文件和存储模型的文件。你必须在 __init__.py 文件中导入这些模块。

比如，若你在 models 目录下有 organic.py 和 synthetic.py：

myapp/models/__init__.pyP

from .organic import Person
from .synthetic import Robot

显式导入每个模块，而不是使用 from .models import * 有助于不打乱命名空间，使代码更具可读性，让代码分析工具更有用。

参见

模型参考: 覆盖所有的模型关联 API，包括模型字段，关联对象和 QuerySet。

Django 2.2.5.dev20190823064900 文档

模型P