I'm currently using Django evolutions to manage my product's database evolutions. It's not perfect but I've learned to live with its flaws. For instance, I always have to copy my production database to test before moving out a new schema because the "evolve" command cannot always evolve a database that was changed in several small migrations (on test I did A->B->C, but A->C will not evolve correctly.)
南方会解决所有这些问题吗？学习一种新工具值得付出努力吗？
我刚开始使用South，我100%相信它.它也是少数几个仍在积极开发中的产品之一.
南方应该能够妥善处理你上面描述的问题.对于数据库的每次更改，它都会创建一个具有"向前"和"向后"两个方法的文件.以下是自动生成的迁移示例:
# > manage.py schemamigration issuetracker added-status-field --auto
# 0004_added-status-field.py
class Migration:
def forwards(self, orm):
# Adding field 'Issue.status'
db.add_column('issuetracker_issue', 'status', orm['issuetracker.issue:status'])
def backwards(self, orm):
# Deleting field 'Issue.status'
db.delete_column('issuetracker_issue', 'status')
关于它的几件好事....
如果你愿意，南方可以让你回滚到特定的迁移
如果您的生产站点在迁移0002上，而您的SVN提交在0004上，则South将执行0003然后0004操作，以使生产数据库达到最新速度.
如果你自己做了改变，你可以告诉南方进行"假"migrations.通常情况下，迁移系统会发出嘶嘶声，但这使得对数据库进行灵活控制变得非常容易.
manage.py migrate [appname] --fake个
如果您需要进行一些自定义操作，比如将一列中的数据复制到另一列，因为迁移文件只是python文件，所以很容易修改向前/向后函数.
在部署了应用程序之后迁移到南方相当容易.最新版本0.6实际上包含了一个命令.
manage.py convert_ to _south [appname]个
当然，我怎么会忘记，我最喜欢的功能是自动生成迁移文件
manage.py schemamigration [appname] [description] --auto
我想我应该为我在开始学习South时犯的错误添加一些提示.并非所有事情都是100%直观的.
在开发数据库上运行Convert_to_South命令之后，不要忘记在生产数据库上运行migrate --fake，否则South会认为它过时了.
如果要创建新应用程序，请使用--initial标志
停止使用manage.py syncdb.真的.
编辑模型是一个3步的过程--
1.)保存模型更改
2.)运行schemamigration --auto分钟
3.)运行migrate将更改提交到数据库
Edit --为了澄清下面的 comments ，核心贡献者正式投票决定不将South包含在版本1.2中.这在一定程度上是因为南方的作者要求尚未将其包括在内.尽管如此，仍然有很多社区支持南方，一些可重用的应用程序制造商开始在他们的应用程序中包括南方的migrations.
Edit #2 --我做了一些更新，以反映来自当前South主干版本的新manage.py命令 struct .根据您正在做的事情，"startMigration"分为"schemamMigration"和"datamMigration".