답변:
다른 지식이있는 사용자들에게는 동의하지 않지만이 경우에는 도움이되지 않습니다. 비 핵심 데이터베이스 테이블의 사용법을 부르는 것은 그 자체로 나쁜 습관 자체는 단순히 잘못입니다.
코어 테이블을 사용할지 또는 자신을 추가 할지를 선택하는 것은 몇 가지 요인에 따라 다릅니다.
쿼리 실행 시간은 테이블 크기에 따라 다릅니다. 따라서 많은 양의 데이터를 저장하려는 경우 이러한 유형의 특정 데이터 세트에만 해당하는 별도의 테이블이 필연적으로 더 효율적인 솔루션이 될 것입니다.
당신이 이러한 특정 데이터 세트와 함께 정기적으로 게시물 또는 CPTS을 많이 저장하는 경우 wp_posts뿐만 아니라로 wp_postmeta빠르게 성장할 수 있습니다.
저에게있어,이 선택은 궁극적으로 데이터가 얼마나 "포스팅"인지에 달려 있습니다. 저자, 의견, 개정, 발췌 등을 지원해야합니까? 그렇다면 CPT 및 / 또는 핵심 기능을 살펴 보겠습니다. 그렇지 않다면 리소스 사용과 효율성을 위해 별도의 테이블을 사용하겠습니다.
Eugene의 개념이 올 바르면 기존의 잘 작성된 플러그인 중 어느 것도 자체 테이블을 추가하지 않을 것입니다. 다행히도 그렇지 않습니다.
$wpdb클래스를 통해 DB 데이터 쿼리, 추가, 수정, 삭제 및 삭제와 관련된 다양한 WordPress 핵심 기능에보다 직관적으로 액세스 할 수 있으므로 데이터를보다 쉽고 안전하게 조작 할 수 있습니다 .wp_options하고 플러그인 개발자가 작성 / 저장되는 데이터 유형을 신중하게 고려하도록하는 등 데이터 분류 및 스토리지에 대한 모범 사례를 장려 / 촉진 합니다. CPT? 분류법입니까? 메타 포스트입니까?그러나 별도의 DB 테이블이 필요한 사용 사례의 경우 WordPress 데이터베이스에 사용자 정의 테이블을 추가하기 위해 WordPress에서 제공하는 방법을 사용해야합니다 . 특히 강력한 $wpdb클래스를 활용할 수 있습니다 . 이 코덱스 항목 목록에있는 정보 / 캐비티에 유의하십시오.
설정 정보 -사용자가 처음 플러그인을 설정할 때 입력 한 사용자 선택 사항, 그 이상으로 커지지 않는 경향이 있습니다 (예 : 태그 관련 플러그인에서 태그 클라우드 형식에 대한 사용자의 선택 사항) 사이드 바). 설정 정보는 일반적으로 WordPress 옵션 메커니즘을 사용하여 저장됩니다.
데이터 -사용자가 플러그인을 계속 사용할 때 추가되는 정보로, 일반적으로 게시물, 카테고리, 업로드 및 기타 WordPress 구성 요소와 관련된 정보가 확장됩니다 (예 : 통계 관련 플러그인, 다양한 페이지보기, 참조 자 등) 및 사이트의 각 게시물과 관련된 기타 통계). 데이터는 별도의 MySQL 테이블에 저장 될 수 있으며,이를 생성해야합니다. 그러나 완전히 새로운 테이블로 뛰어 들기 전에 WordPress의 Post Meta (일명 Custom Fields)에 플러그인 데이터를 저장하면 작동하는지 고려하십시오. 메타 후가 선호되는 방법입니다. 가능하면 실용적으로 사용하십시오.
따라서 다음과 같은 결론을 내릴 수 있습니다.
$wpdb(핵심이 아닌 테이블과 함께 사용하는 것은 내 대답에 암시되어 해당 클래스를 놓치지 않을 것입니다)
비 핵심 데이터베이스 테이블은 데이터가 WordPress 포스트 모델보다 복잡한 경우 필수이며, 데이터 크기가 크며 검색 할 메타 세부 정보가 많이 있습니다.
WordPress가 포스트 메타에 사용하는 EAV 형식은 다중 기준 검색에 적합하지 않습니다.
메타를 여러 항목으로 나누면 게시물 메타 테이블에 게시물 당 많은 항목이 있으며 메타를 통해 게시물을 검색하면 속도가 훨씬 느려집니다.
배열에 직렬화 된 모든 메타를 저장하고 포스트 메타에서 하나의 항목으로 만 보유하면 이번에는 해당 메타 내에서 텍스트 검색 만 수행해야하며 SQL 쿼리에서 직접 비교 연산자를 사용할 수 없습니다.
플러그인에 수천 개의 항목과 관련 메타가없는 경우 큰 문제는 아닙니다.
그러나 플러그인이 큰 일을 할 경우 중요한 문제입니다.
귀하의 상황, 독립 항목으로 된 파일 이름 및 해당 항목에 첨부 된 3 개의 메타 데이터 항목은 그리 크지 않습니다. wordpress post table과 meta table을 사용할 수 있습니다.
그러나 사람들이 특히이 3 가지 메타를 많이 검색하려는 경우 별도의 테이블을 설정하는 것이 좋습니다.
이 형식을 사용하면 하나의 항목 만있는 하나의 테이블 만 있으면됩니다. 여기에는 모든 메타가 포함되어 있어도 괜찮으며 번개를 빠르게 쿼리합니다.
또한 WordPress 테이블을 사용하고 쿼리 캐싱을 사용하는 경우 사용자가 데이터를 검색하면 시간이 지남에 따라 캐시되고로드가 줄어 듭니다. 그러나 별도의 테이블을 수행하는 것만 큼 신중하지는 않습니다.
파일을 미디어 라이브러리에 업로드 할 수 있습니다. 미디어 라이브러리의 각 항목은 wp_posts테이블에 저장됩니다 . 이는 각 파일에 메타 데이터가있을 수 있음을 의미합니다. Metadata APIwp_postmeta 를 사용하여 테이블의 각 파일 당 필요한만큼 정보를 저장할 수 있습니다 .
플러그인에 대한 자체 테이블을 작성하는 것은 나쁜 습관입니까?
예, 핵심 기능을 대신 사용할 수있는 경우 자체 테이블을 만드는 것은 좋지 않습니다.
class TMM {
public static $options;
public static function register() {
self::$options = get_option(TMM_THEME_PREFIX . 'theme_options');
}
public static function get_option($option) {
return @self::$options[$option];
}
public static function update_option($option, $data) {
self::$options[$option] = $data;
update_option($prefix . 'theme_options', self::$options);
}
//ajax
public static function change_options() {
$action_type = $_REQUEST['type'];
$data = array();
parse_str($_REQUEST['values'], $data);
$data = self::db_quotes_shield($data);
if (!empty($data)) {
foreach ($data as $option => $newvalue) {
if (is_array($newvalue)) {
self::update_option($option, $newvalue);
} else {
$newvalue = stripcslashes($newvalue);
$newvalue = str_replace('\"', '"', $newvalue);
$newvalue = str_replace("\'", "'", $newvalue);
self::update_option($option, $newvalue);
}
}
}
_e('Options have been updated.', TMM_THEME_FOLDER_NAME);
exit;
}
public static function db_quotes_shield($data) {
if (is_array($data)) {
foreach ($data as $key => $value) {
if (is_array($value)) {
$data[$key] = self::db_quotes_shield($value);
} else {
$value = stripslashes($value);
$value = str_replace('\"', '"', $value);
$value = str_replace("\'", "'", $value);
$data[$key] = $value;
}
}
}
return $data;
}
}