Django最適合於所謂的green-field開發，即從頭開始的一個項目，正如你在一塊還長着青草的未開墾的土地上從零開始建造一棟建築一般。 然而，儘管Django偏愛從頭開始的項目，將這個框架和以前遺留的數據庫和應用相整合仍然是可能的。 本章就將介紹一些整合的技巧。
與遺留數據庫整合
Django的數據庫層從Python代碼生成SQL schemas—但是對於遺留數據庫，你已經擁有SQL schemas. 這種情況,你需要爲已經存在的數據表創建model. 爲此,Django自帶了一個可以通過讀取您的數據表結構來生成model的工具. 該輔助工具稱爲inspectdb,你可以通過執行manage.py inspectdb來調用它.
使用 inspectdb
inspectdb工具自省你配置文件指向的數據庫，針對每一個表生成一個Django模型，然後將這些Python模型的代碼顯示在系統的標準輸出裏面。
下面是一個從頭開始的針對一個典型的遺留數據庫的整合過程。 兩個前提條件是安裝了Django和一個傳統數據庫。
通過運行django-admin.py startproject mysite (這裏 mysite 是你的項目的名字)建立一個Django項目。 好的，那我們在這個例子中就用這個 mysite 作爲項目的名字。
編輯項目中的配置文件, mysite/settings.py ,告訴Django你的數據庫連接參數和數據庫名。 具體的說，要提供 DATABASE_NAME , DATABASE_ENGINE , DATABASE_USER , DATABASE_PASSWORD , DATABASE_HOST , 和DATABASE_PORT 這些配置信息.。 (請注意其中的一些設置是可選的。 更多信息參見第5章)
通過運行 python mysite/manage.py startapp myapp (這裏 myapp 是你的應用的名字)創建一個Django應用。 這裏我們使用myapp 做爲應用名。
運行命令 python mysite/manage.py inspectdb。這將檢查DATABASE_NAME 數據庫中所有的表並打印出爲每張表生成的模型類。 看一看輸出結果以瞭解inspectdb能做些什麼。
將標準shell的輸出重定向，保存輸出到你的應用的 models.py 文件裏：
python mysite/manage.py inspectdb > mysite/myapp/models.py
編輯 mysite/myapp/models.py 文件以清理生成的 models 並且做一些必要的自定義。 針對這個，下一個節有些好的建議。
清理生成的Models
如你可能會預料到的，數據庫自省不是完美的，你需要對產生的模型代碼做些許清理。 這裏提醒一點關於處理生成 models 的要點:
數據庫的每一個表都會被轉化爲一個model類 (也就是說，數據庫的表和model 類之間是一對一的映射)。 這意味着你需要爲多對多連接的表，重構其models 爲 ManyToManyField 的對象。
所生成的每一個model中的每個字段都擁有自己的屬性，包括id主鍵字段。 但是，請注意，如果某個model沒有主鍵的話，那麼Django會自動爲其增加一個id主鍵字段。 這樣一來，你也許希望移除這樣的代碼行。
id = models.IntegerField(primary_key=True)這樣做並不是僅僅因爲這些行是冗餘的，而且如果當你的應用需要向這些表中增加新記錄時，這些行會導致某些問題。
每一個字段類型，如CharField、DateField， 是通過查找數據庫列類型如VARCHAR,DATE來確定的。如果inspectdb無法把某個數據庫字段映射到model字段上，它會使用TextField字段進行代替，並且會在所生成model字段後面加入Python註釋“該字段類型是猜的”。 對這要當心，如果必要的話，更改字段類型。
如果你的數據庫中的某個字段在Django中找不到合適的對應物，你可以放心的略過它。 Django模型層不要求必須導入你數據庫表中的每個列。
如果數據庫中某個列的名字是Python的保留字（比如pass、class或者for等），inspectdb會在每個屬性名後附加上_field，並將db_column屬性設置爲真實的字段名（也就是pass,class或者for等）。
例如，某張表中包含一個INT類型的列，其列名爲for，那麼所生成的model將會包含如下所示的一個字段：
for_field = models.IntegerField(db_column='for')inspectdb 會在該字段後加注 ‘字段重命名，因爲它是一個Python保留字’ 。
如果數據庫中某張表引用了其他表（正如大多數數據庫系統所做的那樣），你需要適當的修改所生成model的順序，以使得這種引用能夠正確映射。 例如，model Book擁有一個針對於model Author的外鍵，那麼後者應該先於前者被定義。如果你想創建一個指向尚未定義的model的關係，那麼可以使用包含model名的字符串，而不是model對象本身。
對於PostgreSQL,MySQL和SQLite數據庫系統，inspectdb能夠自動檢測出主鍵關係。 也就是說，它會在合適的位置插入primary_key=True。 而對於其他數據庫系統，你必須爲每一個model中至少一個字段插入這樣的語句，因爲Django的model要求必須擁有一個primary_key=True的字段。
外鍵檢測僅對PostgreSQL，還有MySQL表中的某些特定類型生效。 至於其他數據庫，外鍵字段將在假定其爲INT列的情況下被自動生成爲IntegerField。
與認證系統的整合
將Django與其他現有認證系統的用戶名和密碼或者認證方法進行整合是可以辦到的。
例如，你所在的公司也許已經安裝了LDAP，並且爲每一個員工都存儲了相應的用戶名和密碼。 如果用戶在LDAP和基於Django的應用上擁有獨立的賬號，那麼這時無論對於網絡管理員還是用戶自己來說，都是一件很令人頭痛的事兒。
爲了解決這樣的問題，Django認證系統能讓您以插件方式與其他認證資源進行交互。 您可以覆蓋Diango默認的基於數據庫的模式，您還可以使用默認的系統與其他系統進行交互。
指定認證後臺
在後臺，Django維護了一個用於檢查認證的後臺列表。 當某個人調用 django.contrib.auth.authenticate()(如14章中所述)時，Django會嘗試對其認證後臺進行遍歷認證。 如果第一個認證方法失敗，Django會嘗試認證第二個，以此類推，一直到嘗試完。
認證後臺列表在AUTHENTICATION_BACKENDS設置中進行指定。 它應該是指向知道如何認證的Python類的Python路徑的名字數組。 這些類可以在你Python路徑的任何位置。
默認情況下，AUTHENTICATION_BACKENDS被設置爲如下：
('django.contrib.auth.backends.ModelBackend',)那就是檢測Django用戶數據庫的基本認證模式。
AUTHENTICATION_BACKENDS的順序很重要，如果用戶名和密碼在多個後臺中都是有效的，那麼Django將會在第一個正確匹配後停止進一步的處理。
編寫認證後臺
一個認證後臺其實就是一個實現瞭如下兩個方法的類： get_user(id) 和 authenticate(**credentials) 。
方法 get_user 需要一個參數 id ，這個 id 可以是用戶名，數據庫ID或者其他任何數值，該方法會返回一個User 對象。
方法 authenticate 使用證書作爲關鍵參數。 大多數情況下，該方法看起來如下：
class MyBackend(object):
def authenticate(self, username=None, password=None):
# Check the username/password and return a User.但是有時候它也可以認證某個短語，例如：
class MyBackend(object):
def authenticate(self, token=None):
# Check the token and return a User.每一個方法中， authenticate 都應該檢測它所獲取的證書，並且當證書有效時，返回一個匹配於該證書的User 對象，如果證書無效那麼返回 None 。 如果它們不合法，就返回None。
如14章中所述，Django管理系統緊密連接於其自己後臺數據庫的 User 對象。 實現這個功能的最好辦法就是爲您的後臺數據庫（如LDAP目錄，外部SQL數據庫等）中的每個用戶都創建一個對應的Django User對象。 您可以提前寫一個腳本來完成這個工作，也可以在某個用戶第一次登陸的時候在 authenticate 方法中進行實現。
以下是一個示例後臺程序，該後臺用於認證定義在 setting.py 文件中的username和password變量，並且在該用戶第一次認證的時候創建一個相應的Django User 對象。
from django.conf import settings
from django.contrib.auth.models import User, check_password
class SettingsBackend(object):
"""
Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.
Use the login name, and a hash of the password. For example:
ADMIN_LOGIN = 'admin'
ADMIN_PASSWORD = 'sha1$4e987$afbcf42e21bd417fb71db8c66b321e9fc33051de'
"""
def authenticate(self, username=None, password=None):
login_valid = (settings.ADMIN_LOGIN == username)
pwd_valid = check_password(password, settings.ADMIN_PASSWORD)
if login_valid and pwd_valid:
try:
user = User.objects.get(username=username)
except User.DoesNotExist:
# Create a new user. Note that we can set password
# to anything, because it won't be checked; the password
# from settings.py will.
user = User(username=username, password='get from settings.py')
user.is_staff = True
user.is_superuser = True
user.save()
return user
return None
def get_user(self, user_id):
try:
return User.objects.get(pk=user_id)
except User.DoesNotExist:
return None更多認證模塊的後臺, 參考Django文檔。
和遺留Web應用集成
同由其他技術驅動的應用一樣，在相同的Web服務器上運行Django應用也是可行的。 最簡單直接的辦法就是利用Apaches配置文件httpd.conf，將不同的URL類型分發至不同的技術。 （請注意，第12章包含了在Apache/mod_python上配置Django的相關內容，因此在嘗試本章集成之前花些時間去仔細閱讀第12章或許是值得的。)
關鍵在於只有在您的httpd.conf文件中進行了相關定義，Django對某個特定的URL類型的驅動纔會被激活。 在第12章中解釋的缺省部署方案假定您需要Django去驅動某個特定域上的每一個頁面。
<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonDebug On
</Location>
這裏, <Location "/"> 這一行表示用Django處理每個以根開頭的URL.
精妙之處在於Django將指令值限定於一個特定的目錄樹上。 舉個例子，比如說您有一個在某個域中驅動大多數頁面的遺留PHP應用，並且您希望不中斷PHP代碼的運行而在../admin/位置安裝一個Django域。 要做到這一點，您只需將值設置爲/admin/即可。
<Location "/admin/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonDebug On
</Location>有了這樣的設置，只有那些以/admin/開頭的URL地址纔會觸發Django去進行處理。 其他頁面會使用已存在的設置。
請注意，把Diango綁定到的合格的URL（比如在本章例子中的 /admin/ ）並不會影響其對URL的解析。 絕對路徑對Django纔是有效的（例如 /admin/people/person/add/ ），而非截斷後的URL（例如/people/person/add/ ）。這意味着你的根URLconf必須包含前綴 /admin/ 。
Django的數據庫層從Python代碼生成SQL schemas—但是對於遺留數據庫，你已經擁有SQL schemas. 這種情況,你需要爲已經存在的數據表創建model. 爲此,Django自帶了一個可以通過讀取您的數據表結構來生成model的工具. 該輔助工具稱爲inspectdb,你可以通過執行manage.py inspectdb來調用它.
使用 inspectdb
inspectdb工具自省你配置文件指向的數據庫，針對每一個表生成一個Django模型，然後將這些Python模型的代碼顯示在系統的標準輸出裏面。
下面是一個從頭開始的針對一個典型的遺留數據庫的整合過程。 兩個前提條件是安裝了Django和一個傳統數據庫。
通過運行django-admin.py startproject mysite (這裏 mysite 是你的項目的名字)建立一個Django項目。 好的，那我們在這個例子中就用這個 mysite 作爲項目的名字。
編輯項目中的配置文件, mysite/settings.py ,告訴Django你的數據庫連接參數和數據庫名。 具體的說，要提供 DATABASE_NAME , DATABASE_ENGINE , DATABASE_USER , DATABASE_PASSWORD , DATABASE_HOST , 和 DATABASE_PORT 這些配置信息.。 (請注意其中的一些設置是可選的。 更多信息參見第5章)
通過運行 python mysite/manage.py startapp myapp (這裏 myapp 是你的應用的名字)創建一個Django應用。 這裏我們使用myapp 做爲應用名。
運行命令 python mysite/manage.py inspectdb。這將檢查DATABASE_NAME 數據庫中所有的表並打印出爲每張表生成的模型類。 看一看輸出結果以瞭解inspectdb能做些什麼。
將標準shell的輸出重定向，保存輸出到你的應用的 models.py 文件裏：
python mysite/manage.py inspectdb > mysite/myapp/models.py
編輯 mysite/myapp/models.py 文件以清理生成的 models 並且做一些必要的自定義。
python mysite/manage.py inspectdb > mysite/myapp/models.py用該方法得到的model中的類，需要自己修正，比如說 每個表中的字段必須有一個主鍵。
django中利用model想數據庫同步的時候會字段爲你加一個字段id自增的主鍵
清理生成的Models
如你可能會預料到的，數據庫自省不是完美的，你需要對產生的模型代碼做些許清理。 這裏提醒一點關於處理生成 models 的要點:
數據庫的每一個表都會被轉化爲一個model類 (也就是說，數據庫的表和model 類之間是一對一的映射)。 這意味着你需要爲多對多連接的表，重構其models 爲 ManyToManyField 的對象。
所生成的每一個model中的每個字段都擁有自己的屬性，包括id主鍵字段。 但是，請注意，如果某個model沒有主鍵的話，那麼Django會自動爲其增加一個id主鍵字段。 這樣一來，你也許希望移除這樣的代碼行。
id = models.IntegerField(primary_key=True)
這樣做並不是僅僅因爲這些行是冗餘的，而且如果當你的應用需要向這些表中增加新記錄時，這些行會導致某些問題。
每一個字段類型，如CharField、DateField， 是通過查找數據庫列類型如VARCHAR,DATE來確定的。如果inspectdb無法把某個數據庫字段映射到model字段上，它會使用TextField字段進行代替，並且會在所生成model字段後面加入Python註釋“該字段類型是猜的”。 對這要當心，如果必要的話，更改字段類型。
如果你的數據庫中的某個字段在Django中找不到合適的對應物，你可以放心的略過它。 Django模型層不要求必須導入你數據庫表中的每個列。
如果數據庫中某個列的名字是Python的保留字（比如pass、class或者for等），inspectdb會在每個屬性名後附加上_field，並將db_column屬性設置爲真實的字段名（也就是pass,class或者for等）。
例如，某張表中包含一個INT類型的列，其列名爲for，那麼所生成的model將會包含如下所示的一個字段：
for_field = models.IntegerField(db_column='for')
inspectdb 會在該字段後加注 ‘字段重命名，因爲它是一個Python保留字' 。
如果數據庫中某張表引用了其他表（正如大多數數據庫系統所做的那樣），你需要適當的修改所生成model的順序，以使得這種引用能夠正確映射。 例如，model Book擁有一個針對於model Author的外鍵，那麼後者應該先於前者被定義。如果你想創建一個指向尚未定義的model的關係，那麼可以使用包含model名的字符串，而不是model對象本身。
對於PostgreSQL,MySQL和SQLite數據庫系統，inspectdb能夠自動檢測出主鍵關係。 也就是說，它會在合適的位置插入primary_key=True。 而對於其他數據庫系統，你必須爲每一個model中至少一個字段插入這樣的語句，因爲Django的model要求必須擁有一個primary_key=True的字段。
外鍵檢測僅對PostgreSQL，還有MySQL表中的某些特定類型生效。 至於其他數據庫，外鍵字段將在假定其爲INT列的情況下被自動生成爲IntegerField。