仅使用Django的DB部分

仅使用Django的DB部分

如果你喜欢Django的ORM，则“独立”使用它非常简单；我已经写了几种在Web上下文之外使用Django部分的技术，你可以自由使用其中的任何一种（或滚动使用）。

上面的Shane似乎在这方面和其他几点上有误解-例如，Django 可以处理多个不同的数据库，只是没有默认设置（你需要在使用其他模型的模型上做一个自定义管理器比“主”数据库要难一些，并且有一些配方可供选择）。的确，Django本身并没有进行连接管理/连接池，但是我个人总是为此使用外部工具（例如

pgpool

，，它比ORM内置的任何工具都更难动）。

我建议花一些时间阅读并尝试一些可能的Google搜索（例如，我链接到你的帖子是“独立Django脚本”的最佳搜索结果），以使你真正体会到最适合你的内容需求和品味-可能是Django的ORM不适合你，如果不合适，则不应该使用它，但不幸的是，那里存在很多误导信息，使你感到困惑。

编辑以响应Shane：

再次，你似乎被误解了：在运行SQLAlchemy之前，需要对其进行配置（例如，告诉要使用的数据库，如何连接等），因此Django需要类似的配置（通过你选择的方法-你不需要完整的Django设置文件）有什么缺点吗？

至于多数据库支持，你似乎很困惑：支持程度很低。查询对象不是-

QuerySet

，而是

Query

将执行的基础对象知道其连接的数据库，并接受数据库连接作为其初始化参数之一。告诉一个模型使用一个数据库，而另一个模型使用另一个数据库，就像在管理器上设置一个方法一样，该方法将正确的连接信息向下传递到数据库中

Query

。的确，没有为此提供更高级别的API，但这与“不支持”和“要求自定义代码”不同（除非你争辩说，在SQLAlchemy中显式配置多个DB，如果你想要多个，则必须这样做）。 DB，也是“自定义代码”）。

至于你是否最终间接使用了in中没有的东西，那又

django.db

如何呢？就我个人而言，

django.db

导入

django.utils

诸如某些数据结构位和其他代码位不仅对ORM有用的事实，这很好。如果某些东西具有外部依赖性或使用标准的Python库而不是100％独立的，人们可能会抱怨。