我們設計數據庫的時候，早期設計完后，后期發現不完整，要對數據表進行更改，這時候就要用到本屆的知識。
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
