关于数据库：版本跟踪，使用django自动执行数据库架构更改

我目前正在为未来的基于数据库的Web应用程序以及目前用PHP编写的某些应用程序的端口寻找Python框架Django。 过去几年中，最棘手的问题之一是跟踪数据库架构更改并将这些更改部署到生产系统。 我也不敢要求也可以撤消它们，但是当然对于测试和调试这将是一个很棒的功能。 从这里的其他问题(例如这个或这个问题)，我可以看到我并不孤单，这也不是一个小问题。 另外，我从那里的答案中发现了很多灵感。

现在，由于Django似乎非常强大，是否有任何工具可以帮助上述工作？ 甚至在他们的文档中，我都错过了吗？

---

至少有两个第三方实用程序来处理数据库架构迁移，即South和Django Evolution。我都没有尝试过，但是我听说过有关South的一些好消息，尽管Evolution已经存在了一段时间。

另外，请查看Django Wiki上的SchemaEvolution。这只是有关迁移数据库的Wiki页面。

---

上次我检查(版本0.97)时，syncdb将能够添加表以将数据库模式与models.py文件进行同步，但是它不能：

• 重命名或在填充的数据库上添加一列。您需要手工完成。
• 重构模型(例如将表拆分为两个)，并相应地重新填充数据库。

尽管可以编写Django脚本通过与两个不同的管理者一起进行迁移来进行迁移，但是如果您的数据库很大，则可能要花一些时间。

---

最近的DjangoCon上有一个关于数据库模式更改的小组会议；有一个本次会议的视频(感谢Google)，其中应提供一些有关这些实用程序的有用信息。

---

您应该查找Dmigrations，它的功能与django-eveoltions有所不同。
它向您显示了正在执行的所有操作，并向您询问了复杂的操作。应该很棒

---

我听到了很多有关Django Schema Evolution Branch的好消息，这些都是实际用户的选择。通常，它是开箱即用的，可以做它应该做的事情。

---

现在也有移民。从公告：

django-evolution attempts to address this problem the clever way, by detecting changes to models that are not yet reflected in the database schema and figuring out what needs to be done to bring the two back in sync. In contrast, dmigrations takes the stupid approach: it requires you to explicitly state the changes in a sequence of migrations, which will be applied in turn to bring a database up to the most recent state that reflects the underlying models.

This means extra work for developers who create migrations, but it also makes the whole process completely transparent—for our projects, we decided to go with the simplest system that could possibly work.

(我的粗体)

---