将所有内容都放在 Django 模型中是否明智？

Question

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

当前的问题是：该项目包含一个自定义安装.sh 文件，它执行三件事：

1. 创建一些非模型数据库并通过 SQL 导入初始数据
2. 使用 manage.py 导入固定装置
3. 常用的 migrate.pysyncdb 和migrate.py 迁移。

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

我的想法如下：

1. 为每个非模型数据库表生成模型（manage.pyspectdb for a开始，然后在应用程序中分开）。
2. 将所有非 south 模型转换为 south
3. 将初始 SQL 数据转换为 south 固定装置
4. 将数据库备份例程转换为 manage.py dumpdata （并恢复到 manage.py loaddata 固定装置）。
5. 永远不要再使用原始 SQL

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

Answer 1

如果您追求纯粹的非实际 SQL 路线，那么对我来说听起来很理智。

两个小点：

• 3）中的装置实际上是 Django 装置，而不是 South 装置。
• 使用 dumpdata 创建 JSON/XML Django 固定装置然后恢复它们并非没有风险。某些 django.contrib 应用程序（以及许多其他非 contrib 应用程序）可能会由于 FK 冲突等、循环依赖等而导致加载数据痛苦。因此，我建议转储到 SQL 以及固定装置。如果您的服务器在阳光下度假时发生爆炸等情况，原始 SQL 转储对于非 Djangonaut 来说恢复速度会更快

Answer 2

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

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

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

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

将初始 SQL 数据转换为南装置

再次，什么是 South 固定装置？

将数据库备份例程转换为 manage.py dumpdata（并恢复到 manage.py loaddata 固定装置）。

我对此不太确定。我发现数据库特定的备份和恢复解决方案比manage.py 使用得更频繁。特别是如果您有遗留触发器/存储过程等。

永远不要再使用原始 SQL

理论上很好。请记住，您有时必须挖掘 SQL。只要您不以此作为与 SQL 失去联系的理由，或者以此为借口不让自己的双手“脏”在 SQL 上，那么就可以继续。