Django框架應用中models.py文件與資料庫操作問題？

01-26

初學者請教如下幾個問題：
1，models.py文件中的class 命名有沒有什麼要求（比方說大小寫）？同步資料庫時怎麼樣能夠生成資料庫與models.py中名字一致的表？
2,models.py文件中給class新增了屬性，同步時會要求輸入一個一次性的默認值。請教添加默認值的原由，及其是否有所功能。

3，如何區別manage.py syncdb , manage.py makemigrations(manage.py migrate)。

1.本身沒有任何要求，只要是個類名，然後表名不重複就可以。說PEP規範的，你不遵守人家照樣給你建表，你高興就好。當然，為了保證代碼可讀性，還是應該遵循一些規範的（比如PEP，或者你就是不鳥PEP也沒關係，自己弄套規範出來也沒人攔著你）。至於表名，在沒有改寫Meta子類的情況下默認應該是app名_class名這種樣式。但是可以通過改寫Meta的db_table屬性來指定表。

2.Django在默認情況下欄位是不允許NULL的（當然你可以可以在構造時寫上參數允許NULL）。當你添加了一個新欄位然後migrate的時候，當表裡已有記錄時，這些記錄在新欄位處沒有值，又不許填NULL，總得有個什麼玩意給填進去，這就是default。當然如果你指定這個欄位NULL=True，那也可以不要default，orm會直接給他個NULL。

3.django 1.7以上版本保留syncdb大概只是為了做向下兼容，與老版本的syncdb效果相同，建立數據表，但是沒有數據遷移的功能，也就是如果表不為空他就罷工了。migrate的作用在於你修改了model結構，仍然可以保留已有的表內數據記錄，而更改表結構。makemigrations是掃描變動後在本地的app目錄下的migrations包里生成遷移用的代碼，但是並不會執行。migrate則是根據migrations包下的代碼操作資料庫，但並不檢查models的修改變動。所以更改models後應先makemigrations然後migrate。

問題1，在Meta裡面定義db_table屬性就可以確定表名

問題2，因為你添加的欄位是非空的（沒有設置null=True）,makemigration的時候當然要問你要默認值來賦給這張表裡面已有的數據

問題3，syncdb已經不用了，makemigration用來自動根據model定義變更生成變更單（也就是migration文件）

migrate根據migration文件將變更應用到資料庫中。

也就是，你改了表，就先makemigration，然後到伺服器上migrate

1、models.py中的class也是很平常的子類，只不過繼承於django.db中的models.Model，看一下源碼中django/db/這個folder

backends中放著不同資料庫的實現，我們用的所有的model來自models中的base.py對於model的具體實現，migrations這個文件夾就是你第三個問題問到的migrate和makemigrations，等下說。

既然是個類，那麼命名的格式就是一樣的，參見2.7文檔 9. Classes 3.4文檔 9. Classes

具體到命名的規則，要多看代碼以及你上司的喜好和部門的規定了，比如騰訊AlloyTeam對於前端的明明規範就很好 Code Guide by @AlloyTeam

在models.py中定義表名，例子：

class Course(models.Model): name = CharField(db_column=name, max_length=200, blank=True, verbose_name=name)

class Meta: db_table = course # 這句定義了table的名字

2、沒聽懂

3、migrate和makemigrations從django1.7開始出現，在此之前，migrate存在於South中。

可以看出django的ORM在這一點上和sqlalchemy越發的相似了，make migrations 基本等於sqlalchemy的db migrate，migrate等於sqlalchemy中的db upgrade。只不過區別是在一個flask項目中，sqlalchemy習慣把version保存在project層面下，針對所有app；而django的version仍然保持其urls文件分離的風格，保存在每一個app文件夾下。

從我們開發者的角度理解就是sql的語句的書寫和執行分開了，model的變化全部體現在你每一個app下的migrations中的版本。這樣的好處就是，我們可以手動修改sql語句，算是多了個可控可調試的階段吧。

這樣從1.7之後我們在django中的同步資料庫的流程就變成了:

1、創建app

2、書寫x_app下的model

3、python manage.py makemigrations x_app 這一步將sql語句收集起來，但是沒有同步資料庫

4、python manage.py migrate 同步到資料庫中

tips: 使用python manage.py makemigrations針對全局進行檢測，經常出現No changes detected，所以最好還是加option指定app，也讓開發更規範。