EntityFieldQuery不可用于对字段数据运行聚合函数（SUM，AVG等），因为它与SQL无关。也就是说，合法地需要不时地运行此类操作。根据具有EntityFieldQuery尤其是EntityFieldQuery的SQL函数以及如何使用聚合函数SUM，ARG和MAX，需要使用SQL查询，并且这种方法最适合我的用例。昨天我在与@chx交谈时，他建议使用几个内部函数来查找字段名称和列名称。我只是想知道这是否可持续，是否适合在我可能发布给其他人的代码库中进行。
如果这是最好的方法，那就是最好的方法。我绝对不敢做，因为它感觉很乱。
Answers:
“ 视图”字段模块允许您将字段表作为基本表公开给视图。这与Views的默认行为不同，基表是字段表，而不是从中将字段数据加载到的实体。例如，当选择节点作为基础表时，您可以添加字段，但是查询中的主表（基础表）仍然是节点，根据数据，这些节点可能会破坏聚合函数（也就是某些函数的多对一关系）字段）。
“视图”字段使您可以直接访问字段表，这意味着聚合函数可以正常工作。另外，如果您需要对其他字段表进行“有趣的”联接，则可以使用以下命令完全控制它们。
/**
* Implements hook_views_data_alter().
*/
function mymodule_views_data_alter(&$data) {
views_field_add_multi_join($data, /* see docs */);
}它使用起来非常简单，并且允许您一次在多个字段表之间执行聚合函数。然后，您可以手动调用视图$view->execute()并将结果从视图中拉出。在视图文档中有此示例。
与EntityFieldQuery相比，此方法的好处是您可以在Views中管理该过程（几乎每个人都已经在使用它），并允许它以不太直接的方式执行物理查询构建，这有助于提高将来的故障率。另外，很多时候您会希望在管理屏幕上显示此类汇总数据，然后可以使用该视图提供显示并以代码形式访问结果以用于其他目的。
可以在视图的附加模块中完成此操作吗？它可以很好地处理查询，并且某些结果通过聚合函数发布，例如在上下文过滤器发生故障时可以默认为所有值并对每个可用结果计数的操作中。用于查询的功能应该存在，但需要UI形式。让我知道这是否有意义。我只是开始剖析观点并进行推测。
_field_sql_storage_tablename($field)和_field_sql_storage_columnname($field_name, $column），但它并不可持续，因此，如果有人愿意回答这个问题，我仍然很感兴趣。