Django模型中的所有东西都合情合理吗？

Question

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

目前的问题是：项目包含一个自定义install.sh文件，它有三个功能：

1. 创建一些非模型数据库并通过SQL导入初始数据
2. 使用manage.py
导入灯具
3. 通常的migrate.py syncdb和migrate.py migrate。

（install.sh还包含一些实现半成品south依赖关系管理的逻辑，我将其替换为native one）

我的想法如下：

1. 为每个非模型数据库表生成模型（manage.py inspectdb表示开始，之后在应用中拆分）。
2. 将所有非south模型转换为south
3. 将初始SQL数据转换为south灯具
4. 将数据库备份例程转换为manage.py dumpdata（并恢复为manage.py loaddata灯具。）
5. 永远不再使用原始SQL

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

Answer 1

如果您正在使用纯粹的非实际SQL路由，那对我来说听起来很健全。

两个小问题：

• 3）中的灯具实际上是Django灯具，而不是南方灯具。
• 使用dumpdata创建JSON / XML Django fixtures，然后恢复它们并非没有风险。由于循环依赖等原因，某些django.contrib应用程序（以及许多其他非贡献应用程序）可能会因FK冲突等而导致loaddata痛苦。所以，我建议转储到SQL以及fixtures。如果你的服务器在阳光下度假时爆炸，非Djangonaut可以更快地恢复原始SQL转储等。

Answer 2

  

为每个非模型数据库表生成模型（manage.py inspectdb开始，之后在应用程序中拆分）。

听起来不错。您可能希望在此基础上继续使用此功能。从你需要的那些开始。

  

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

我不太了解非南方模式。如果您的意思是为所有现有模型生成南迁移（然后在迁移期间可能--fake），那么是的，这是有道理的。

  

将初始SQL数据转换为南方灯具

再一次，什么是南方赛道？

  

将数据库备份例程转换为manage.py dumpdata（并恢复为manage.py loaddata灯具。）

我对这个不太确定。我看到数据库特定的备份和恢复解决方案的使用频率高于manage.py。特别是如果你有传统的触发器/存储过程等。

  

永远不再使用原始SQL

理论上很好。请记住，您在某些时候必须挖掘SQL。只要您不将此作为与SQL失去联系的理由，或者将其作为不让您的手“弄脏”SQL的借口，那么请继续。