创建模型:
在你的开发环境中，已经有一个“项目” —— 已经建立起来，你将开始在上面做一些东西。
Django自带一个工具，它可以自动生成应用的基本目录结构，这样你就能专心于书写代码而不是创建目录。
项目 vs. 应用
一个应用可以运用到多个项目中。
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通过这个历史记录更新你的数据库模式使它与你现在的模型文件保持一致。
Question关联。
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，每个字段中保存着什么类型的数据。
你将在Python代码中使用到它的值，并且你的数据库将把它用作表的列名。
对于这个模型中其他的字段，机器可读的名字（实例名）足以充分地表达出它的含义。
这个参数不仅用于数据库模式，而且数据验证中也会用到，我们稍后会看到。
默认值 为0。
Django支持所有常见的数据库关联：多对一、多对多和一对一。
激活模型
有了这些代码，Django就能够：
- TABLE 语句）。
- Choice对象创建一个访问数据库的python API。
polls应用已经安装。
理念
Django 应用是可以“热插拔”的，即可以在多个项目中使用同一个应用，也可以分发这些应用， 因为它们不需要与某个特定的Django安装绑定。
所以它现在是这样的：
## mysite/settings.py INSTALLED_APPS = ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', '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不要求你在每次Django生成迁移文件之后都要阅读这些文件，但是它们被设计成可人为编辑的形式，以便你可以手工稍微修改一下Django的某些具体行为。
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。
- （你可以重写这个行为。)
- （你也可以重写这个行为。)
- 。（是的，你依然可以重写这个行为。）
- 它只是告诉PostgreSQL直到事务的最后再执行外键关联。
- 在处理字段名的引号时也是如此 —— 例如，使用双引号还是单引号。
- 这对于检查Django将要进行的数据库操作或者你的数据库管理员需要这些SQL脚本是非常有用的。
它会检查你的项目中的模型是否存在问题，而不用执行迁移或者接触数据库。
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
django_migrations的特殊表来追踪哪些迁移文件已经被应用过），并且在你的数据库上运行它们 —— 本质上来讲，就是使你的数据库模式和你改动后的模型进行同步。
请记住实现模型变更的三个步骤：
- models.py文件中）。
- makemigrations ，为这些修改创建迁移文件
- migrate ，将这些改变更新到数据库中。
这样做不仅可以使开发变得更加简单，而且对其他开发者以及上线生产非常有用。
manage.py 工具能做的所有事情。