我们设计数据库的时候，早期设计完后，后期发现不完整，要对数据表进行更改，这时候就要用到本届的知识。
Django 1.7.x和后来的版本：
Django1.7.x及以后的版本继承了South的功能，在修改models.py了后运行：
python manage.py makemigrations
python manage.py migrate
这两行命令就会对我们的models.py进行检测，自动发现需要改进的，应用到数据库中去。
Django1.6.x及以前：
写过Django项目的同学，必然后遇到这个问题：
在Django1.6及以前的版本中，我们测试，当代县model要改，怎么办？
我们修改了models.py之后，我们运行：
python manage.py syncdb
这句话将我们在models.py中新加的类创建响应的表
对于原有的，现在删除了的类，Django会询问是否要删除数据库中已经存在的相关数据表
如果在原来的类上增加字段或者删除字段，可以参考这个命令
python manage.py sql appname
给出得 SQL语句，然后自己手动到数据库执行SQL，但是这样非常容易出错
Django 的第三方app south 就是专门做数据库表结构自动迁移工作JacobKaplan-Moss 曾做过一次调查，South名列最受欢迎的而第三方app，事实上，他现在已经成为Django数据库表迁移标准，很多第三方app都会带South migratins脚本，Django1.7中继承了South的功能。
1、安装South
student@student-VirtualBox:~$ sudo pip install
[sudo] password for student:
student@student-VirtualBox:~$ sudo pip install South
[sudo] password for student:
Downloading/unpacking South
Downloading South-1.0.2.tar.gz (96Kb): 96Kb downloaded
Running setup.py egg_info for package South
Installing collected packages: South
Running setup.py install for South
Successfully installed South
Cleaning up...
student@student-VirtualBox:~$
2、使用方法
一个好的程序使用起来必定是简单的，South和它的宗旨一样，使用简单，只需要简单几步，针对已经建好的model和创建完表的应用
把south 加入到settings.py中的INSTALL_APPS中
# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'blog',
'south',
]
修改好后运行一次，python manage.py syncdb，Django会新建一个south_migrationhistory表，用来记录数据表更改（
Migration）的历史记录
$ python manage.py syncdb
Syncing...
Creating tables ...
Creating table south_migrationhistory
Installing custom SQL ...
Installing indexes ...
No fixtures found.
Synced:
> django.contrib.admin
> django.contrib.auth
> django.contrib.contenttypes
> django.contrib.sessions
> django.contrib.messages
> django.contrib.staticfiles
> blog
> south
Not synced (use migrations):
如果要把之前建好号的比如blog 这个app使用South来管理：
$ python manage.py convert_to_south blog
你会发现blog文件夹中多了一个 migrations 目录，里面有一个 0001_initial.py 文件。
注：如果 blog 这个 app 之前就创建过相关的表，可以用下面的来“假装”用 South 创建（伪创建，在改动 models.py 之前运行这个）
python manage.py migrate blog --fake
意思是这个表我以前已经建好了，用 South 只是纪一下这个创建记录，下次 migrate 的时候不必再创建了。
原理就是 south_migrationhistory 中记录下了 models.py 的修改的历史，下次再修改时会和最近一次记录比较，发现改变了什么，然后生成相应的对应文件，最终执行相应的 SQL 更改原有的数据表。
接着，当你对 Blog.models 做任何修改后，只要执行：
$ python manage.py schemamigration blog --auto
South就会帮助我们找出哪些地方做了修改，如果你新增的数据表没有给default值，并且没有设置null=True, south会问你一些问题，因为新增的column对于原来的旧的数据不能为Null的话就得有一个值。顺利的话，在migrations文件夹下会产生一个0002_add_mobile_column.py，但是这一步并没有真正修改数据库的表，我们需要执行 python manage.py migrate ：
$ python manage.py migrate
Running migrations for blog:
- Migrating forwards to 0002_add_mobile_column.
> blog:0002_add_mobile_column
- Loading initial data for blog.
No fixtures found.
这样所做的更改就写入到了数据库中了。
恢复到以前
South好处就是可以随时恢复到之前的一个版本，比如我们想要回到最开始的那个版本：
> python manage.py migrate blog 0001
- Soft matched migration 0001 to 0001_initial.
Running migrations for blog:
- Migrating backwards to just after 0001_initial.
< blog:0002_add_mobile_column
这样就搞定了，数据库就恢复到以前了，比你手动更改要方便太多了。
####### django1.7后集成south的使用方法
对于app间有依赖关系的初始化，先在settings中将其他app注掉，同步主表，然后再打开其他app同步
1、初始部署代码，初始化数据库，建表但没有对app注册migratie
python manage.py makemigrations
python manage.py migrate
# 此时字段并不能被migrate检测到，无法变更字段，
此命令作为整个工程初始化数据库是使用，主要用于
初始化User等标准库
2、对已有数据库的app转化为migrate
python manage.py makemigrations app_name
python manage.py migrate app_name --fake-inital
# 即可初始化。之后app中字段变动有以下两中方式修改
# a) 修改所有注册过migrate的app
python manage.py makemigrations
python manage.py migrate
# b)单独修改APP
python manage.py makemigrations app_name
python manage.py migrate app_name
3.新增app,还未创建数据库的
python manage.py makemigrations app_name
python manage.py migrate app_name
4.对于工具类app的model，不需要修改，则不需要注册migrate