创建模型:
在你的开发环境中，已经有一个“项目” —— 已经建立起来，你将开始在上面做一些东西。
你编写的每个Django应用都是一个遵循特定约定的Python包。 Django自带一个工具，它可以自动生成应用的基本目录结构，这样你就能专心于书写代码而不是创建目录。
项目 vs. 应用
项目和应用之间有什么不同？ 应用是一个Web应用程序，它完成具体的事项 —— 比如一个博客系统、一个存储公共档案的数据库或者一个简单的投票应用。 项目是一个特定网站中相关配置和应用的集合。一个项目可以包含多个应用。一个应用可以运用到多个项目中。
你的应用可以放在Python path上的任何位置。在本教程中，我们将在你的manage.py文件同级目录创建我们的投票应用，以便可以将它作为顶层模块导入，而不是mysite的子模块。
确保你在与manage.py相同的目录下，并且键入以下CMD命令来创建你的应用：
python manage.py startapp polls
这将创建一个目录polls，它的结构如下：
polls/
__init__.py
admin.py
migrations/
__init__.py
models.py
tests.py
views.py
我们的投票应用将基于这个目录结构。
当编写一个数据库驱动的Web应用时，第一步就是定义该应用的模型 —— 本质上，就是定义该模型所对应的数据库设计及其附带的元数据。
理念
模型指出了数据的唯一、明确的真实来源。 它包含了正在存储的数据的基本字段和行为。 Django遵循DRY (Don't repeat yourself)原则。这个原则的目标是在一个地方定义你的数据模型，并从它自动获得需要的信息。
迁移工具也符合以上哲学 —— 这不同于Ruby On Rails中的迁移；例如，迁移完全依照于你的模型文件且本质上只是一个历史记录，Django通过这个历史记录更新你的数据库模式使它与你现在的模型文件保持一致。
在这个简单的投票应用中，我们将创建两个模型： Question和Choice。Question对象具有一个question_text（问题）属性和一个publish_date（发布时间）属性。 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) 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。这个参数不仅用于数据库模式，而且数据验证中也会用到，我们稍后会看到。
Field 还具有各种可选参数。在这个例子中，我们设置votes字段的默认值 为0。
最后，注意我们使用ForeignKey定义了一个关联。它告诉Django每个Choice都只关联一个Question。Django支持所有常见的数据库关联：多对一、多对多和一对一。
激活模型
上面那段简短的模型代码给了Django很多信息。 有了这些代码，Django就能够：
- 为该应用创建数据库表（CREATE TABLE 语句）。
- 为Question对象和Choice对象创建一个访问数据库的python API。
但是，我们首先得告诉项目：polls应用已经安装。
理念
Django 应用是可以“热插拔”的，即可以在多个项目中使用同一个应用，也可以分发这些应用， 因为它们不需要与某个特定的Django安装绑定。
再次编辑mysite/settings.py文件，并修改INSTALLED_APPS设置以包含字符串'polls'。所以它现在是这样的：
## mysite/settings.py INSTALLED_APPS = ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'polls', )
现在Django知道要包含polls应用。 让我们运行另外一个CMD命令：
python mange.py makemigrations polls
你应该看到类似下面的内容：
Migrations for 'polls':
0001_initial.py:
- Create model Question
- Create model Choice
- Add field question to choice
通过运行makemigrations告诉Django，已经对模型做了一些更改（在这个例子中，你创建了一个新的模型）并且会将这些更改存储为迁移文件。
Django使用迁移文件来保存对模型的更改（即数据库模式的更改）—— 所谓迁移文件其实就是磁盘上的普通文件。 如果愿意，你可以阅读迁移文件来了解新模型； 这个迁移文件就是 polls/migrations/0001_initial.py。不用担心，Django不要求你在每次Django生成迁移文件之后都要阅读这些文件，但是它们被设计成可人为编辑的形式，以便你可以手工稍微修改一下Django的某些具体行为。
有一个命令可以运行这些迁移文件并自动管理你的数据库模式 —— 它叫做migrate，我们一会儿会用到它 —— 但是首先，让我们看一下迁移行为将会执行哪些SQL语句。sqlmigrate命令接收迁移文件的名字并返回它们的SQL语句：
$ python manage.py sqlmigrate polls 0001
你应该会看到类似如下的内容（为了便于阅读我们对它重新编排了格式）：
BEGIN;
CREATE TABLE "polls_choice" (
"id" serial NOT NULL PRIMARY KEY,
"choice_text" varchar(200) NOT NULL,
"votes" integer NOT NULL
);
CREATE TABLE "polls_question" (
"id" serial NOT NULL PRIMARY KEY,
"question_text" varchar(200) NOT NULL,
"pub_date" timestamp with time zone NOT NULL
);
ALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;
ALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;
CREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");
ALTER TABLE "polls_choice"
ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"
FOREIGN KEY ("question_id")
REFERENCES "polls_question" ("id")
DEFERRABLE INITIALLY DEFERRED;
COMMIT;
请注意以下几点：
- 输出的具体内容会依据你使用的数据库而不同。 以上例子使用的数据库是PostgreSQL。
- 表名是自动生成的，由app的名字（polls）和模型名字的小写字母组合而成 —— question和choice。（你可以重写这个行为。)
- 主键（IDs）是自动添加的。 （你也可以重写这个行为。)
- 按照惯例，Django会在外键的字段名后面添加 "_id"。（是的，你依然可以重写这个行为。）
- 外键关系由FOREIGN KEY约束显式声明。不用在意DEFERRABLE部分；它只是告诉PostgreSQL直到事务的最后再执行外键关联。
- 这些SQL语句是针对你所使用的数据库定制的，所以会为你自动处理某些数据库所特有的字段例如auto_increment (MySQL)、 serial (PostgreSQL)或integerprimary key autoincrement (SQLite) 。在处理字段名的引号时也是如此 —— 例如，使用双引号还是单引号。
- sqlmigrate命令并不会在你的数据库上真正运行迁移文件 —— 它只是把Django 认为需要的SQL打印在屏幕上以让你能够看到。 这对于检查Django将要进行的数据库操作或者你的数据库管理员需要这些SQL脚本是非常有用的。
如果有兴趣，你还可以运行python manage.py check；它会检查你的项目中的模型是否存在问题，而不用执行迁移或者接触数据库。
现在，再次运行migrate以在你的数据库中创建模型所对应的表：
$ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: staticfiles, messages
Apply all migrations: admin, contenttypes, polls, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying <migration name>... OK
migrate命令会找出所有还没有被应用的迁移文件（Django使用数据库中一个叫做django_migrations的特殊表来追踪哪些迁移文件已经被应用过），并且在你的数据库上运行它们 —— 本质上来讲，就是使你的数据库模式和你改动后的模型进行同步。
迁移功能非常强大，可以让你在开发过程中不断修改你的模型而不用删除数据库或者表然后再重新生成一个新的 —— 它专注于升级你的数据库且不丢失数据。 我们将在本教程的后续章节对迁移进行深入地讲解，但是现在，请记住实现模型变更的三个步骤：
- 修改你的模型（在models.py文件中）。
- 运行python manage.py makemigrations ，为这些修改创建迁移文件
- 运行python manage.py migrate ，将这些改变更新到数据库中。
将生成和应用迁移文件的命令分成几个命令来执行，是因为你可能需要将迁移文件提交到你的版本控制系统中并跟随你的应用一起变化； 这样做不仅可以使开发变得更加简单，而且对其他开发者以及上线生产非常有用。
阅读django-admin 的文档来了解manage.py 工具能做的所有事情。