我們將設定資料庫，建立您的第一個模型，並介紹 Django 快速自動生成的管理站點。

資料庫設定

現在 , 使用dsite/settings.py
這是一個正常的Python模組，模組級變數代表Django設定。

預設情況下，配置使用SQLite。

如果你是資料庫新手，或者你只是想嘗試Django，這是最簡單的選擇。
SQLite包含在Python中，所以你不需要安裝任何東西來支援你的資料庫。

但是，當開始你的第一個真正的專案時，你可能想要使用一個更可擴充套件的資料庫

比如PostgreSQL，以避免資料庫切換的麻煩。

如果您希望使用其他資料庫，請安裝相應的資料庫繫結，並在專案中更改為以下鍵中所對應的模組   以匹配資料庫連線設定：

ENGINE -  
'django.db.backends.sqlite3'
'django.db.backends.postgresql'
'django.db.backends.mysql'
'django.db.backends.oracle'

其他 backends 中的資料庫模組也可用。

NAME - 

你的資料庫的名字 如果使用的是SQLite，則資料庫將成為您計算機上的檔案;
在這種情況下，NAME 應該是該檔案的完整絕對路徑，包括檔名。
預設把檔案儲存在你的專案目錄中

os.path.join(BASE_DIR, 'db.sqlite3')

如果你不使用SQLite作為資料庫，額外設定

例如 USER，PASSWORD和HOST等必須值。

對於SQLite以外的資料庫

如果你使用SQLite之外的資料庫，請確保你已經建立了一個數據庫。在資料庫的互動式提示符下用“ ”來做。CREATE DATABASE database_name;

還要確保提供的資料庫使用者 dsite/settings.py 具有“建立資料庫”許可權。
這允許自動建立一個 測試資料庫，這將在以後需要。

如果你正在使用SQLite，你不需要事先建立任何東西 - 資料庫檔案將在需要時自動建立。

在編輯時mysite/settings.py，請設定TIME_ZONE為您的時區。

另外，請注意INSTALLED_APPS檔案頂部的設定。
它包含在此Django例項中啟用的所有Django應用程式的名稱。

應用程式可以在多個專案中使用，您也可以將其打包並分發給其他專案中的其他人使用。
預設情況下，INSTALLED_APPS包含以下應用程式
所有Django都附帶了這些應用程式：

django.contrib.admin         - admin管理網站。你會很快使用它。
django.contrib.auth          - 一個認證系統。
django.contrib.contenttypes  - 內容型別的框架。
django.contrib.sessions      - 會話框架。
django.contrib.messages      - 一個訊息框架。
django.contrib.staticfiles   - 一個管理靜態檔案的框架。

但是，這些應用程式至少使用了一個數據庫表
所以我們需要在資料庫中建立表，然後才能使用它們。
為此，請執行以下命令：

python manage.py migrate

該migrate 命令將檢視該 INSTALLED_APPS 設定

並根據 dsite/settings.py 檔案中的資料庫設定以及應用程式隨附的資料庫設定進行遷移（稍後將介紹這些資料庫遷移）
並建立任何必需的資料庫表。

您將看到每個遷移所應用的訊息。
如果您有興趣，請為您的資料庫執行命令列

type \dt (PostgreSQL),
SHOW TABLES; (MySQL)
.schema (SQLite)
SELECT TABLE_NAME FROM USER_TABLES; (Oracle) 

to display the tables Django created.

預設的應用程式包含在常見的情況下，但不是每個人都需要它們。
如果您不需要其中的任何一項或全部，請在migrate根據INSTALLED_APPS執行之前
註釋或刪除相應的行
該 migrate命令將僅執行INSTALLED_APPS應用程式的遷移 。

建立資料表單models

現在定義資料庫中 - 資料庫表單 （table），元資料（欄位）

原理

一個你的資料模型是與你的實際操作相關。它包含要儲存資料的重要欄位和行為。 Django遵循DRY原則。目標是在一個地方定義你的資料模型，並從中自動派生出來。

這包括migration - 與Ruby On Rails不同
例如，migrate應用的model檔案，本質上只是Django可以滾動更新資料庫模式以匹配當前模型 的歷史記錄。

在我們簡單的應用Poll中，我們將建立倆個models：

問題model 和 選擇model
一個問題包含一個問題和出版時間，
一個選擇有倆個field，choice文字field和投票，每個選擇項都和問題有關

這些概念由簡單的Python類表示。

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, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

程式碼很簡單。
每個model由一個django.db.models.Model類的子類表示。

每個model都有許多類變數，每個變數名錶示model中的資料庫欄位。

每個欄位由一個Field類的例項表示

例如
字元欄位的CharField和日期時間的DateTimeField。
這告訴Django每個欄位包含什麼型別的資料。

每個Field例項（例如question_text或pub_date）的名稱是機器友好格式的欄位名稱。
您將在您的Python程式碼中使用此值，並且您的資料庫將使用它作為列名稱。

您可以使用可選的第一個位置引數來指定一個可讀的名稱。
如：

pub_date = models.DateTimeField('date published')

這在Django的一些內省部分中被使用，而且它也被用作文件。
如果未提供此欄位，則Django將使用機器可讀的名稱（pub_date）。
在這個例子中，我們只為Question.pub_date定義了一個人類可讀的名字。
對於此模型中的所有其他欄位，該欄位的機器可讀名稱就足以作為其人類可讀的名稱。

一些Field類需要引數。

例如：

CharField，要求你給它一個max_length。
這不僅在資料庫模式中使用，我們將很快看到在驗證中使用

一個欄位也可以有各種可選的引數

例：

在這種情況下，我們將投票的預設值設定為0。
votes = models.IntegerField(default=0)

最後，注意使用ForeignKey定義了一個關係。
這告訴Django每個Choice都與一個Question相關。

Django支援所有常見的資料庫關係：多對一，多對多和一對一。

實現models

將用一小部分model程式碼給Django提供了很多資訊。
有了它，Django能夠：

為應用建立資料表

Create a database schema (CREATE TABLE statements) for this app.

建立一個Python資料庫訪問API 來訪問Question和Choice物件。

Create a Python database-access API for accessing Question and Choice objects.

但首先我們需要告訴我們的專案，Polls的應用程式已包含進專案中。

原理

Django應用程式是“可插入的”: 您可以在多個專案中使用一個應用程式, 你可以分發應用程式, 因為它們不必繫結到給定的Django安裝。

要將該應用程式包含在我們的專案中，我們需要在INSTALLED_APPS設定中新增對其Config類的引用。

PollsConfig類在polls / apps.py檔案中，所以它的虛擬路徑是“polls.apps.PollsConfig”。
編輯mysite / settings.py檔案並將該虛線路徑新增到INSTALLED_APPS設定。
程式碼:

INSTALLED_APPS = [
    'polls.apps.PollsConfig',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

現在Django知道包含了Polls應用程式。

執行命令,讓專案知道該為外部應用polls新增資料表單

python manage.py makemigrations polls

可以看到下面輸出(為polls進行資料遷移)

Migrations for 'polls':
  polls/migrations/0001_initial.py:
    - Create model Choice
    - Create model Question
    - Add field question to choice

通過執行 makemigrations,
可以告訴 Django 您已經對models進行了一些更改（在這種情況下，您已經建立了新模型），並且希望將這些更改 儲存到資料庫中。

Django 執行migration 是如何將更改儲存到model（以及資料庫模式） ？

這些model只是磁碟上的檔案。 如果你喜歡，你可以閱讀你的新模型的遷移。
對應檔案是 polls / migrations / 0001_initial.py。
不要擔心，Django每次建立時都不會讀取它們，但是如果您想手動調整Django如何更改model內容，那麼它們就是可編輯的。

可以為你執行遷移，並自動管理你的資料庫模式 - 這就是所謂的migrate命令

但是首先我們來看看遷移過程將怎樣執行SQL。
sqlmigrate命令 通過名稱遷移 並返回它們的SQL：

python manage.py sqlmigrate polls 0001

您應該看到類似於以下的內容（為了便於閱讀，我們將其重新格式化）：
確切的輸出將取決於您使用的資料庫。下面的例子是為PostgreSQL生成的。

BEGIN;
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
--
-- Create model Question
--
CREATE TABLE "polls_question" (
    "id" serial NOT NULL PRIMARY KEY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- Add field question to choice
--
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;

請注意以下幾點：

• 表（table）名稱是通過將應用程式的名稱（polls）和models中繼承model的類的小寫名稱（question和choice）組合而自動生成的。 （您可以覆蓋此行為。）

• 主鍵（ID）自動新增。 （你也可以重寫這個。） 按照慣例，Django將“_id”附加到外來鍵欄位名稱。 （是的，你也可以重寫這個。）

• 外來鍵關係通過FOREIGN KEY約束來顯式化。不要擔心DEFERRABLE部分;這只是告訴PostgreSQL在事務結束之前不執行外來鍵。

• 它是針對您正在使用的資料庫而量身定製的，因此自動為您處理特定於資料庫的欄位型別

  例如 auto_increment（MySQL），serial（PostgreSQL）或 整數主鍵自動增量（SQLite）

  欄位名稱的引用也是如此

  例如使用雙引號或單引號。

• sqlmigrate 命令實際上並不在資料庫上執行遷移 - 它只是將其列印到螢幕上，以便您可以看到SQL (Django認為是必需的)。

  這對於檢查Django將要做什麼
  或者如果對有需要通過SQL指令碼進行更改的資料庫管理員很有用。

• 如果你有興趣，你也可以執行python manage.py check;

  這將檢查您的專案中的任何問題，而無需進行遷移或觸控資料庫。

現在，再次執行遷移以在資料庫中建立這些模型表：

python manage.py migrate

輸出如下：

  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Rendering model states... DONE
  Applying polls.0001_initial... OK

migrate命令執行所有尚未應用的遷移

（Django使用名為django_migrations的資料庫中的特殊表跟蹤哪些應用）
並根據資料庫執行它們 - 本質上，將對模型所做的更改與模式同步 在資料庫中。

migrate 是非常強大的

隨著時間的推移，您可以逐步改變模型，而不需要刪除資料庫或表
專門用於實時升級資料庫，且不會丟失資料。

我們將在本教程的後面部分更深入地介紹migrate，但現在請記住進行模型更改的三步指南：

進行模型更改的三大基本步驟

1. 更改 models (在應用的 models.py 中實現).
2. 執行python manage.py makemigrations為這些更改建立migrations,並新增到專案中
3. 執行python manage.py migrate 按照最終migrations表,將未實現的migrations應用到資料庫。

有單獨的命令來進行和應用遷移的原因是 ：

因為您將提交migration到您的版本控制系統並將它們與您的應用程式一起上線;
它們不僅使您的開發更容易，而且還可以被其他開發人員和生產使用。

閱讀django-admin文件以獲取有關manage.py實用程式可以執行的操作的完整資訊。