필드에 대한 집계 정보를 얻는 가장 지속 가능한 방법은 무엇입니까?

EntityFieldQuery는 SQL과 무관하므로 필드 데이터에서 집계 함수 (SUM, AVG 등)를 실행하는 데 사용되지 않습니다. 즉, 그러한 작업은 때때로 합법적으로 실행되어야합니다. 에 따르면 SQL의 EntityFieldQuery와 기능 , 특히 EntityFieldQuery 방법 집계 함수 SUM, ARG와 MAX를 사용하는 방법 , SQL 쿼리를 사용할 필요가 있고, 그 방법은 내 유스 케이스 최고의 맞습니다. 나는 어제 @chx와 이야기하고 있었고 필드 이름과 열 이름을 찾기 위해 몇 가지 내부 함수를 사용하는 것이 좋습니다. 이것이 지속 가능한지 궁금하고 코드베이스에서 otehrs로 릴리스 할 수 있는지 궁금합니다.

그것이 가장 좋은 방법이라면, 가장 좋은 방법입니다. 나는 그것이 지저분한 느낌 때문에 절대적으로 확신하기 전에 그것을하고 싶지 않습니다.

보기 필드 모듈은 뷰에 기본 테이블로 필드 테이블을 표시 할 수 있습니다. 이것은 기본 테이블이 필드 테이블이며 필드 데이터가로드되는 엔티티가 아니라는 점에서 뷰 기본 동작 과 다릅니다 . 예를 들어 노드를 기본 테이블로 선택할 때 필드를 추가 할 수 있지만 쿼리의 기본 (기본 테이블)은 여전히 ​​노드이므로 데이터에 따라 집계 함수 (일부 일대일 관계)를 망칠 수 있습니다. 노드에 필드).

뷰 필드를 사용하면 필드 테이블에 직접 액세스 할 수 있으므로 집계 함수가 올바르게 작동합니다. 또한 다른 필드 테이블에 "관심있는"조인을 수행해야하는 경우 다음을 사용하여 완전히 제어 할 수 있습니다.

/**
 * Implements hook_views_data_alter().
 */
function mymodule_views_data_alter(&$data) {
  views_field_add_multi_join($data, /* see docs */);
}

사용하기가 간단하고 여러 필드 테이블에서 한 번에 집계 함수를 수행 할 수 있습니다. 그런 다음 수동으로 뷰를 호출하고 뷰 $view->execute()에서 결과를 가져올 수 있습니다. 뷰 문서에 이에 대한 예가 있습니다.

EntityFieldQuery에 비해이 접근 방식의 이점은 뷰에서 프로세스를 관리하고 (거의 모든 사용자가 이미 사용중인) 실제 쿼리 작성을 덜 직접적인 방식으로 수행하여 가능한 분석을 향상시킬 수 있다는 것입니다. 또한 이러한 집계 데이터를 관리자 화면에 여러 번 표시하여 뷰를 사용하여 추가 목적으로 코드를 표시하고 결과에 액세스 할 수 있습니다.

뷰에 대한 애드온 모듈에서이 작업을 수행 할 수 있습니까? 쿼리를 잘 처리하고 일부 결과는 컨텍스트 필터가 실패 할 때 모든 값을 기본값으로 사용하고 각 결과에서 사용 가능한 결과를 계산할 수있는 경우와 같은 집계 함수와 함께 집계됩니다. 쿼리에 대한 기능이 있어야하지만 UI 양식이 필요합니다. 이것이 의미가 있는지 알려주십시오. 나는 방금 전망을 분석하기 시작하고 있으며 추측하고 있습니다.