하나의 "올바른"방법이 있다고 말하는 사람은 회의적이어야합니다. 올바른 방법은 상황에 따라 다릅니다. CPT 인프라를 사용하면 다음과 같은 많은 이점이 있습니다.
- 당신은 무료로 대시 보드 UI를 얻을
- 설치시 사용중인 영구 캐시 플러그인을 포함하여 WP 캐싱을 자동으로 활용합니다.
- 수정 후 게시물과 같은 혜택을 자동으로받습니다.
WP_Query클래스에 액세스하면 이론적으로는 버그가 많고 취약하며 비효율적 인 SQL을 작성할 필요가 없습니다.- 플러그인을 배포하거나 오픈 소스 개발을 위해 개방 할 계획이라면 개발자가 자신의 사용자 정의 항목보다 사용자 정의 게시물 유형 및 관련 API 기능을 사용하는 것이 더 편할 수 있습니다.
CPT API의 문제점은 주로 '게시물'의 은유와 은유와 함께 제공되는 데이터 유형의 모든 측면과 밀접하게 관련되어 있다는 사실에서 비롯됩니다. MySQL 명령 행에서를 실행하십시오 DESCRIBE wp_posts. WP는 콘텐츠에 제목이 있고 (단일) 저자가 있고, 생성 된 날짜와 마지막으로 편집 한 날짜 만 추적해야하며, 색인 post_content이 생성 되지 않은 공간이 필요하다고 가정 합니다. 일부 콘텐츠에는 적합하지만 다른 콘텐츠에는 해당되지 않습니다. 당신은 이미 몇 가지 잠재적 인 문제의 방향으로 몸짓을했습니다 :
만약 내가 그 길로 가면 물건이 "까다로워 질 것"이라면 cpt 당 여분의 필드에 필요한 포스트 메타 필드의 수
wp_postsCPT API를 통해 스키마 를 보강하는 방법은 postmeta와 taxonomies의 두 가지가 있습니다 . Postmeta는 인덱싱되지 않은 키-값 쌍으로, 여러 가지 기타 데이터를 저장하는 데는 좋지만 복잡한 조회를 수행하기에는 전혀 최적화되지 않았습니다. 분류법은 이와 관련하여 다소 융통성이 있지만, 조회가 매우 복잡한 경우 잠재적으로 비용이 많이 드는 하위 쿼리가 여전히 많이 발생합니다. ( meta_query및 tax_query인수와 쿼리 생성자 클래스는 매우 훌륭하고 편리합니다.)
제안한대로 가끔 보고서의 경우 이러한 종류의 "세미 복잡한 관계형 필터" 만 수행하면이 아키텍처가 적합 할 것입니다. 필터를 사용자에게 노출하기 시작할 때가되므로 많은 복잡한 JOINs 및 하위 쿼리를 항상 실행해야하므로 문제가 신속하게 해결됩니다.
관계를 가장 잘 관리하는 방법, 특히 많은 관계가있는 경우
다 대다 관계는 WP dev 커뮤니티에서 오랫동안 고집하고 있습니다 ( https://core.trac.wordpress.org/ticket/14513 참조 ). 분류 항목을 post_ids에 매핑하여 사용자 정의 테이블을 사용하지 않고 위조 할 수 있습니다 (예 : P3에 'Y-P3'이라는 태그가 있다고 말하면 'P3은 Y와 P5의 관계가 있음'이라고 말할 수 있음) (그리고 비효율적) 매우 빠르게. CPT를 서로 연결하는 고유 한 관계 테이블을 만드는 것도 고려할 수 있습니다. CPT의 이점을 여전히 누릴 수 있으며 단일 DB 테이블 만 만들 수 있습니다. 이 방법의 잘 실행 된 버전은 게시물 2 게시물 플러그인을 참조하십시오 : https://wordpress.org/extend/plugins/posts-to-posts/
따라서 결국 다음을 기반으로 결정해야합니다.
- 저장할 데이터의 종류- "게시"방법
- 필요한 쿼리 종류-얼마나 복잡한가
- 규모-원하는 스키마의 복잡성, 총 개체 수 및 예상되는 사용자 수
대답이 다음과 같은 경우 : 매우 복잡하고 복잡하지 않으며 초 거대를 확장 할 필요가 없으면 CPT를 사용하십시오. 그렇지 않으면 자신의 테이블을 고려하십시오.