一直都是使用 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