一直都是使用 Django 框架進行 Web 后台的開發，喜歡它的大而全，也一直都覺得 Django 對業務的處理方式更加嚴謹，更加細節，特別是它內置的 ORM，用起來感覺非常棒，開發效率高，能節省開發人員非常多的時間，至於它一直被人詬病的性能問題，相信 Django3.0 進入異步時代以后，一切都會有所改觀。
新項目使用到了 Flask，說實話，真的無法喜歡 Flask 這個框架（話說真正的大牛都是自己寫框架，只有搬運工才會糾結哪個框架會更好用），也許是我用 Django 真的太久了，思維已經慣性，但是確實覺得 Flask 實在過於寬松，不是我喜歡的那種東西。
既然使用了 Flask，很顯然就需要繼續尋找一個第三方的 ORM 庫，實現對數據庫的 CRUD 操作（佩服直接懟 SQL 語句的大佬），如果是我本人 ， SQLAlchemy 顯然就會成為不二選擇，如果使用了 SQLAlchemy，那么就需要一個數據庫的遷移工具，有一個 alembic 工具就可以實現，事實上它也是 SQLAlchemy 的作者開發出來的，用起來確實很不錯（以我本人用 Flask 的經歷，就是先把它拼湊成一個低配版的 Django，然后再進行業務開發，可既然如此，為什么我不一開始就選擇 Django 呢？應該是我技術素養不夠，無法理解 Flask 的理念和精華吧！）
鑒於我確實不怎么喜歡 Flask，所以這里就不對這個 alembic 工具，復制太多的使用介紹了，網上一抓一大把，這里姑且當做一個記錄吧，要看就去看官方文檔：
https://alembic.sqlalchemy.org/en/latest/
https://alembic.sqlalchemy.org/en/latest/tutorial.html
我增加一些網絡上不怎么搜索到，但是卻又實用的，比如說，在一個項目中，我們使用了多個數據庫，或者創建了多個數據表，在進行遷移時希望能指定應用進行遷移：
一、alembic.ini 配置文件中：
[app1] script_locations = "app1應用的env.py文件所在的目錄" version_locations = "app1應用生成的遷移版本文件所在的目錄" [app2] script_locations = "app2應用的env.py文件所在的目錄" version_locations = "app2應用生成的遷移版本文件所在的目錄"
# env.py 我理解為應用的遷移管理文件
二、在使用 alembic 進行遷移時，使用 -n 指定應用進行遷移
# 將應用加入遷移版本控制 alembic -n {應用名稱} init migrations # 生成遷移文件 alembic -n {應用名稱} revision --autogenerate -m "遷移說明" # 進行遷移 alembic -n {應用名稱} upgrade head