Question

可以/应该使用任何ORM解决方案是这样的复杂情况吗？甚至可以使用Propel或Doctrine完成此操作吗？目前我正在使用Propel。如果有Propel解决方案，我会很高兴。
如果我直接查询推荐是什么建议？

SELECT I.*,((I.width*175)/I.height) as relativeWidth FROM 
(SELECT * FROM Image WHERE owner = 1 LIMIT 5, 10) I
order by relativeWidth asc

此外，在需要在应用程序的大多数位置执行非常复杂的查询的场景的标准解决方案是什么？

我用于分页的LIMIT 5, 10。它在内部查询中。如果它在视图中如何控制分页？

Answer 1

您的查询可以使用Propel 1.6.3编写如下：

<?php

// SELECT * FROM Image WHERE owner = 1 LIMIT 5, 10
$subQuery = ImageQuery::create()
    ->filterByOwner(1)
    ->limit(10)
    ->offset(5)
    ;

$query = ImageQuery::create()
    ->addSelectQuery($subQuery, 'I', true)
    ->withColumn('((I.WIDTH*175)/I.HEIGHT)', 'relativeWidth') // ((I.width*175)/I.height) as relativeWidth
    ->orderBy('relativeWidth') // default is 'asc'
    ;

$params = array();
var_dump(\BasePeer::createSelectSql($query, $params));

输出是：

SELECT I.ID, I.WIDTH, I.HEIGHT, I.OWNER, ((I.WIDTH*175)/I.HEIGHT) AS relativeWidth
FROM (
    SELECT image.ID, image.WIDTH, image.HEIGHT, image.OWNER
    FROM `image`
    WHERE image.OWNER=:p1 LIMIT 5, 10
) AS I
ORDER BY relativeWidth ASC

请注意:p1是与所有者值相关的绑定参数。

因此使用Propel创建复杂查询非常简单：）

威廉

Answer 2

有些查询最好用视图修复，imo。确实，这不适用于ORM纯粹主义者，但我发现它是一种非常可维护的方法，同时获得了ORM的好处。我会说，在一个项目中，你应该只在10％的时间左右这样做;如果您发现正在为大多数ORM语句编写视图，那么可能需要采用另一种方法。

大家都这么说，你引用的例子很简单。我倾向于在对等类中使用原始SQL编写一个特殊的方法，并根据我在相关问题上的示例手动补充它。请记住，在运行原始sql时，更容易成为SQL注入的牺牲品 - 记得要逃避，清理或参数化你的变量。

用于真正复杂查询的ORM解决方案

2 个答案: