扩展Django的ORM[译]

2019年10月2日 156次阅读 来源: 木头lbj

注：译文，原文地址http://blog.safaribooksonline.com/2013/11/06/extending-the-django-orm/

Django的对象关系映射(ORM)在代码和数据库之间搭起了一架桥梁。这篇文章中我打算简要的说下什么是ORM以及该怎么去使用它。最重要的是怎么使用专门的SQL定制和扩展ORM。
最后，我会说几点为什么在不选择标准ORM时需要特别的小心。现在开始吧。

ORM的什么吸引我?

首先，也是最重要的，ORM会将业务逻辑封装进应用中，而不是使用数据库。将应用的业务逻辑放进ORM让我们的代码更容易理解和维护。他让我们不用再一直去猜应用到底是怎么工作的。

ORM帮我们在数据库返回和插入数据时进行验证。在对数据的完整性和安全性非常关心的应用中，这一步是起决定性作用的。虽然数据库中的类型检查也非常的棒，但是Django的ORM能帮助
我们在数据没有到达数据库的时候验证业务规则。此外，也能保证数据库返回的数据是我们所期望的。

MyModelClass.objects.all() 是ORM的一个非常简单的使用ORM的例子。这行代码返回数据表中的所有内容，与select * from MyModelTable结果一样。还有很多其他的用法,
这不是这篇文章的关注的。在你开始使用定制的SQL语句之前你将会非常想知道ORM是怎么工作的。

为什么我需要定制ORM?

在实践中，我见过几个例子。首先是当没有明显的查询方法的时候你会这么想。然而这对于定制ORM不是一个很好的假定。当你需要使用SQL的时候，试着使用对象和对象关系来思考，而不是使用数据表。
这可能会得到一个很好的查询方法。举个例子，很多的SQL用户也许想写下面的语句:

SELECT
"user_user"."id", "user_user"."password",  
"user_user"."last_login", "user_user"."name",
"user_user"."date", "user_user"."level"  
FROM  
"user_user"
INSERT JOIN  
"address_address"
ON ("user_user"."id" = "address_address"."user_id")
WHERE ("user_user"."name" IN (hello, world) AND "address_address"."street" = main)

如果这些数据模型创建的正确的话，相应的Python代码非常简单:

User.objects.filter(name__in=['hello', 'world'], address_street='main')

对于倾向使用SQL的用户，我建议常常往回退一步。对于Python/Django的重度用户，我建议记住用SQL的思维来想想将会创建的是什么。使用SQL来扩展和定制的原因更正确的说应该是：
有一个非常特殊的逻辑或者能获得更好的ORM不能提供的性能。

我怎么定制查询?

第一个定制查询的选择是使用extra方法，文档很详细。Django文档中提供了很棒的例子。
我将会使用raw来完成一个很好的用例，raw的文档同样很棒。然而这些例子都不怎么重要。
我想让你通过ORM来使用用先进数据库特性的优势。

举个例子，现在你的应用需要展现一个聚合了很多值的大数据，需要创建大量的SQL语句。第一步，你将创建一个存储过程来封装这个查询，然后创建一个SQL function来让方便调用这个查询（你同样需要
创建一个数据表，但那都是标准的SQL）。为了性能，你也许你将这个逻辑移到了数据库中去处理。所以，这时候你的应用只能在数据库完成数据聚合的时候才能处理业务逻辑。

我们同样假设你有一个名为aggregate_profile_metrics的SQL方法来帮助你的应用提高性能。使用标准的ORM的话你就没这么幸运了。SQL方法只有在使用views和tables的时候才能使用。现在看看raw
查询的威力。首先定义一个model。

class ProfileMetric(models.Model):
    avg_posts_per_day = models.IntegerField()
    avg_comments_per_day = models.IntegerField()
    avg_respondees_per_day = models.IntegerField()

    class Meta():
        managed = False
        db_table = 'fake_table_name'  # This is the trickier part

注意这个model是完全与数据相关的，我们能够在我们所有不同的数据表中进行聚合调用。当数据库足够大，你拥有数十个表和数百万用户的时候，这个表就有一定规模了。由于这些数据很可能随时更新，这时候SQL方法
的效率优势就显示出来了。现在进入最有趣的部分，使用下面的方法你将很容易达到调用SQL方法的目的。

query = "select avg_posts_per_day, avg_comments_per_day, avg_respondees_per_day 
         from table(aggregate_profile_metrics(%s))"  

profile_metrics = ProfileMetric.objects.raw(query, [283844238])

使用上面的查询你能够调用SQL方法，但是这太痛苦了。注意，这个SQL方法调用了一个参数user_id来获取数据，但是我们没有将参数直接传递进去。如果你的SQL方法不需要调用参数，你应该使用数据库的view。
使用这个方法，你现在可以使用profile_metics,除了一些细小的区别外，就像使用一个一般的queryset一样（查看RawQUeryset和一般Queryset的区别）。

除了这点，Django还允许用户不通过model进行数据库操作。我极力反对这么做。记住不使用model直接进行数据库操作是没多少理由的。那些使用了这个的例子都是非常极端的情况。只要使用了不基于model的raw查询，
ORM的作用就消失了。从这点来说，就没有使用Django的必要了。

当使用.raw的时候，需要记住一下几点。

  1. 确认这些查询不能使用Django的ORM完成。

  2. 确认需要去创建定制的SQL(比如:为了获得SQL function的性能或者是在遗留应用中进行的操作)。

  3. 通过QuerySet中的.raw来创建你定制的SQL调用。

  4. 不要直接使用connection的curser.execute。

现在，你知道Django的ORM是非常强大的。当你想使用SQL语句和命令的时候记住这一点。记住下面关于何时使用raw SQL的建议。

  1. 不要使用raw SQL(当你能用其他办法解决的时候)。

  2. 使用ORM中的对象关系。

  3. 试着在使用raw前使用extra，

  4. 将raw作为最后一个选择。

    原文作者：木头lbj
    原文地址: https://segmentfault.com/a/1190000000334852
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞