一些別的ORM，比如Hibernate，會提供自動更新schema的方式。但是SQLAlchemy不會，它本身沒有提供修改表結構（schema）的方式。它這麼做也是有它的理由：一般在開發及維護過程中，風險最高的動作就是改動schema，因此這一步最好由手動完成，透過對於SQL資料庫的直接更新以實現對最終效果的精準控制，避免出現意想不到的情況。另一方面，可能SQLAlchemy的開發者覺得改動schema的邏輯相對複雜，把這項工作獨立出來，另行開發了Alembic。此外， SQLAlchemy-Migrate 是另一個已有的比較完善的工具。解決辦法（根據具體場景選擇其一）：1. 對於非生產環境的資料庫，在確保安全的前提下可以直接“炸庫”（即將資料庫中所有資料及表結構都刪除），透過SQLAlchemy的
一些別的ORM，比如Hibernate，會提供自動更新schema的方式。但是SQLAlchemy不會，它本身沒有提供修改表結構（schema）的方式。它這麼做也是有它的理由：一般在開發及維護過程中，風險最高的動作就是改動schema，因此這一步最好由手動完成，透過對於SQL資料庫的直接更新以實現對最終效果的精準控制，避免出現意想不到的情況。另一方面，可能SQLAlchemy的開發者覺得改動schema的邏輯相對複雜，把這項工作獨立出來，另行開發了Alembic。此外， SQLAlchemy-Migrate 是另一個已有的比較完善的工具。解決辦法（根據具體場景選擇其一）：1. 對於非生產環境的資料庫，在確保安全的前提下可以直接“炸庫”（即將資料庫中所有資料及表結構都刪除），透過SQLAlchemy的
自動建立表結構。優點是省時；缺點是風險高，只有在內測環境且資料量已經備份的前提下方可使用，2. 透過SQL的“ALTER Table”語句，手動修改表結構。優點是比炸庫相對更安全，缺點是如果表結構的改動比較多，工作量會比較大。3. Alembic 和 SQLAlchemy-Migrate 。前者由 SQLAlchemy 的作者開發，後者是原來的SQLAlchemy內嵌的模組