让Django模型中的一切都合理吗？

我刚刚继承了一个Django项目，用于维护和持续开发。虽然我是一名相当熟练的程序员（也是Python），但我几乎没有使用Django的经验，因此我需要对我的想法进行一些理智的检查；）

当前的问题是：该项目包含一个自定义的

install.sh

文件，该文件有三个功能：

创建一些非模型数据库并通过SQL导入初始数据

使用

manage.py导入装置

通常的

migrate.py-syncdb

和

migrate.py-migrate

（

install.sh

还包含一些逻辑来实现半成品的

south

依赖关系管理，我将其替换为a）

我的想法如下：

为每个非模型数据库表生成模型（

manage.py-inspectdb

首先，然后在应用程序中拆分）

将所有非

south

车型转换为

south

将初始SQL数据转换为

south

fixtures

将数据库备份例程转换为

manage.py dumpdata

（并还原为

manage.py loaddata

fixtures）

永远不要再使用原始SQL

现在一个简单的问题是：这个计划明智吗？有哪些替代方案

为每个非模型数据库表生成模型（首先是manage.py inspectdb，然后在应用程序中拆分）

听起来不错。不过，您可能希望在此基础上继续使用。立即从你需要的开始

将所有非南方模式转换为南方模式

我不太明白非南方模式是什么。如果您的意思是为所有现有模型生成向南迁移（然后可能在迁移过程中生成它们），那么是的，这是有意义的

将初始SQL数据转换为原始数据

再说一遍，什么是南方赛程

将数据库备份例程转换为

manage.py dumpdata

（并还原为

manage.py loaddata

fixtures）

这件事我不太确定。我见过比使用

manage.py

更频繁地使用特定于数据库的备份和恢复解决方案。特别是如果您有遗留触发器/存储过程等

永远不要再使用原始SQL

---

理论上很好。请记住，您将在某个时候不得不挖掘SQL。只要你不以此为理由与SQL失去联系，或以此为借口不让SQL“弄脏”你的手，那么是的，继续吧。

如果你追求的是一条完全没有实际意义的SQL路线，对我来说听起来就够理智的了

两点：

• 3）中的装置实际上是Django装置，而不是南方装置
• 使用dumpdata创建JSON/XML Django装置并恢复它们并非没有风险。某些django.contrib应用程序（以及许多其他非contrib应用程序）可能会因FK冲突等、循环依赖等而导致loaddata问题。因此，我建议将其转储到SQL以及Fixture。如果您在阳光下度假时服务器发生爆炸，非Djangonaut用户恢复原始SQL转储会更快

---

好吧，你抓住我了，我必须修正我的术语：）“非南方模式”——没有南方迁移的模式，对吗。“

south

fixtures”--我认为自动导入数据是一个

south

功能，似乎是Django的。所以，正常情况下：）数据库备份——我基本上只谈论数据；触发器/过程（如果有）将单独备份。我正在尝试建立一个基线，以便通过测试进行快速迭代，为此，我希望能够快速建立一个sane数据库。可能只适合开发，不适合生产。@nikolai prokoschenko在备份生产服务器时，应该转储整个数据库。我还建议您定期将当前生产中的数据复制到dev，以便开发相关数据。然后匿名（伪造/覆盖所有密码、用户名、人名、位置、电子邮件，取决于你的应用程序）生成测试数据。作为Django新手，我首先尝试遵循“主要路线”，即尽可能使用Django ORM。我很快就会知道我是否能一直坚持下去。。。