本文是Django系列文章，请到无聊才读书的博客了解更多详细信息。
编写第一个Django应用，第2部分
本教程从教程1的中断处开始。我们将设置数据库，创建您的第一个模型，并快速介绍Django的自动生成的管理站点。
数据库设置
现在，打开mysite/settings.py。这是一个普通的Python模块，具有表示Django设置的模块级变量。
默认情况下，配置使用SQLite。如果您不熟悉数据库，或者只是对尝试使用Django感兴趣，这是最简单的选择。SQLite包含在Python中，因此您不需要安装其他任何东西即可支持数据库。但是，在开始第一个实际项目时，您可能希望使用可扩展性更高的数据库（例如PostgreSQL），以避免数据库切换麻烦。
如果您希望使用另一个数据库，请安装适当的数据库绑定并在项目中更改以下键 以匹配您的数据库连接设置：DATABASES 'default'
-
ENGINE-要么'django.db.backends.sqlite3'，'django.db.backends.postgresql'，'django.db.backends.mysql'，或'django.db.backends.oracle'。也可以使用其他后端。 -
NAME–数据库的名称。如果您使用的是SQLite，则数据库将是您计算机上的文件；在这种情况下，NAME应为该文件的完整绝对路径，包括文件名。默认值会将文件存储在您的项目目录中。os.path.join(BASE_DIR, 'db.sqlite3')
如果你不使用SQLite作为数据库，额外的设置，例如 USER，PASSWORD和HOST必须加入。有关更多详细信息，请参见参考文档DATABASES。
对于SQLite以外的数据库
如果您使用的是SQLite以外的数据库，请确保此时已创建数据库。在数据库的交互式提示中使用“ ”进行操作。CREATE DATABASE database_name;还要确保提供的数据库用户
mysite/settings.py具有“创建数据库”特权。这样可以自动创建 测试数据库，这在以后的教程中将需要。如果您使用的是SQLite，则无需事先创建任何内容-数据库文件将在需要时自动创建。
在编辑时mysite/settings.py，将其设置TIME_ZONE为您的时区。
另外，请注意INSTALLED_APPS文件顶部的设置。该名称包含在此Django实例中激活的所有Django应用程序的名称。应用程序可以在多个项目中使用，您可以打包和分发它们，以供其他人在其项目中使用。
默认情况下，INSTALLED_APPS包含以下应用程序，所有这些应用程序都随Django一起提供：
-
django.contrib.admin–管理站点。您将很快使用它。 -
django.contrib.auth–认证系统。 -
django.contrib.contenttypes–内容类型的框架。 -
django.contrib.sessions–会话框架。 -
django.contrib.messages–消息传递框架。 -
django.contrib.staticfiles–用于管理静态文件的框架。
默认情况下，这些应用程序是为方便起见而包含的。
但是，其中一些应用程序至少使用一个数据库表，因此我们需要在数据库中创建表之后才能使用它们。为此，请运行以下命令：
$ python manage.py migrate
该migrate命令将查看该INSTALLED_APPS设置，并根据mysite/settings.py文件中的数据库设置以及应用程序随附的数据库迁移来创建任何必要的数据库表（我们将在后面介绍）。您将看到一条适用于每次迁移的消息。如果您有兴趣，请为数据库运行命令行客户端，然后键入\dt（PostgreSQL），（MySQL）， （SQLite）或（Oracle）以显示Django创建的表。SHOW TABLES;``.schema``SELECT TABLE_NAME FROM USER_TABLES;
对于极简主义者
就像我们上面说的，普通情况下包括默认应用程序，但并不是每个人都需要它们。如果不需要它们中的任何一个或全部，请
INSTALLED_APPS在运行之前随时注释掉或删除相应的行migrate。该migrate命令将仅针对中的应用运行迁移INSTALLED_APPS。
创建模型
现在，我们将定义您的模型-本质上是您的数据库布局以及其他元数据。
哲学
模型是有关数据的唯一，确定的事实来源。它包含要存储数据的基本字段和行为。Django遵循DRY原则。目标是在一处定义您的数据模型并自动从中派生数据。
其中包括迁移-例如，与Ruby On Rails不同，迁移完全是从您的模型文件派生的，并且实质上只是Django可以滚动以更新数据库模式以匹配当前模型的历史记录。
在简单的民意调查应用中，我们将创建两个模型：Question和Choice。一个Question有一个问题和出版日期。A Choice有两个字段：选择的文本和投票提示。每个Choice都与关联Question。
这些概念由简单的Python类表示。编辑 polls/models.py文件，使其如下所示：
polls/models.py
from django.db import models
class Question(models.Model):
question_text = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
class Choice(models.Model):
question = models.ForeignKey(Question, on_delete=models.CASCADE)
choice_text = models.CharField(max_length=200)
votes = models.IntegerField(default=0)
代码很简单。每个模型由子类的类表示django.db.models.Model。每个模型都有许多类变量，每个类变量代表模型中的数据库字段。
每个字段都由一个Field 类的实例表示–例如，CharField对于字符字段和 DateTimeField日期时间。这告诉Django每个字段保存什么类型的数据。
每个Field实例的名称（例如 question_text或pub_date）是该字段的名称，采用机器友好的格式。您将在Python代码中使用此值，数据库将使用它作为列名。
您可以使用可选的第一个位置参数 Field来指定人类可读的名称。在Django的几个自省部分中使用了该功能，并且它还作为文档使用。如果未提供此字段，则Django将使用机器可读的名称。在此示例中，我们仅为定义了易于理解的名称Question.pub_date。对于此模型中的所有其他字段，该字段的机器可读名称将足以作为其人类可读的名称。
一些Field类具有必需的参数。 CharField例如，要求您给它一个 max_length。我们将很快看到，它不仅用于数据库模式，而且用于验证。
A Field也可以具有各种可选参数；在这种情况下，我们将default值 设置votes为0。
最后，注意使用定义了一个关系 ForeignKey。这告诉Django每个Choice都与一个相关Question。Django支持所有常见的数据库关系：多对一，多对多和一对一。
激活模型
少量的模型代码为Django提供了很多信息。有了它，Django能够：
- 为此应用程序创建数据库架构（语句）。
CREATE TABLE - 创建用于访问
Question和Choice对象的Python数据库访问API 。
但是首先我们需要告诉我们的项目该polls应用程序已安装。
哲学
Django应用程序是“可插拔的”：您可以在多个项目中使用一个应用程序，并且可以分发应用程序，因为它们不必绑定到给定的Django安装中。
要将应用程序包含在我们的项目中，我们需要在设置中添加对其配置类的引用INSTALLED_APPS。该 PollsConfig班是在polls/apps.py文件中，所以它的虚线路径'polls.apps.PollsConfig'。编辑mysite/settings.py文件并将该虚线路径添加到INSTALLED_APPS设置中。它看起来像这样：
mysite/settings.py
INSTALLED_APPS = [
'polls.apps.PollsConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]