Якщо я хочу зберегти налаштування для свого плагіна, то це досить легко і прямо вперед.
Тепер я хотів би трохи більше зберегти в базі даних.
Ім'я файлу та 3 інші значення, які стосуються лише цього файлу. І є багато файлів із тими значеннями. Чи можливо зберегти вид підрядників за допомогою вбудованих методів бази даних? Як я можу видалити та сортувати їх тощо?
Відповіді:
Я рідко не погоджуюся з іншим обізнаним користувачам, але в цьому випадку я не можу в цьому допомогти. На мою думку, називати використання непрофільних таблиць баз даних поганою практикою як такої просто просто неправильно.
Вибір того, чи слід використовувати основні таблиці чи додавати власні, залежить від кількох факторів.
Час виконання запиту залежить від розміру таблиці. Отже, якщо ви плануєте зберігати значну кількість даних, окрема таблиця, що обслуговує лише цей один тип певних наборів даних, неминуче стане більш ефективним рішенням.
Якщо ви зберігаєте багато регулярних публікацій або CPT поряд із цими конкретними наборами даних, вони wp_postsтакож wp_postmetaможуть швидко зростати.
Для мене цей вибір в кінцевому рахунку залежить від того, наскільки "розміщуються" дані. Чи повинна вона підтримувати автора, коментарі, редакції, уривки тощо? Якщо так, я перейду з CPT та / або основними функціоналами. Якщо ні, я перейду з окремими таблицями заради використання ресурсів та ефективності.
Якби поняття Євгенія було правильним, жоден із існуючих добре написаних плагінів не додав би власні таблиці, що, на щастя, не так.
$wpdbклас .wp_options, а також змушує розробника плагінів уважно розглянути тип створюваних / зберігаються даних - чи це CPT? це таксономія? це пост мета?Однак для тих випадків використання, коли потрібна окрема таблиця БД, не забудьте скористатися методом, передбаченим WordPress для додавання вашої користувальницької таблиці до бази даних WordPress , тим більше, що ви можете скористатися потужним $wpdbкласом. Зверніть увагу на інформацію / застереження цього списку записів Codex:
Інформація про налаштування - вибір користувача, який вводиться, коли користувач вперше налаштовує ваш плагін, і не прагне значно перевищувати це (наприклад, у плагіні, пов’язаному з тегами, вибір користувача щодо формату хмари тегів у бічна панель). Інформація про налаштування зазвичай зберігається за допомогою механізму параметрів WordPress.
Дані - інформація, яка додається, коли користувач продовжує використовувати ваш плагін, який, як правило, розширює інформацію, пов’язану з публікаціями, категоріями, завантаженнями та іншими компонентами WordPress (наприклад, у плагіні, пов’язаному зі статистикою, різних переглядах сторінок, рефератах та інші статистичні дані, пов’язані з кожною публікацією на вашому сайті). Дані можна зберігати в окремій таблиці MySQL, яку доведеться створити. Перш ніж зайти до цілої нової таблиці, врахуйте, чи зберігатиметься дані вашого плагіна в «Мета мета WordPress» (він же - «Custom Fields»). Post Meta є кращим методом; використовувати його, коли це можливо / практично.
Таким чином, ми можемо зробити висновок про наступне:
$wpdb(використання цього переходу з непрофільними таблицями малося на увазі у моїй відповіді, не хотів би пропустити цей клас)
Не основні таблиці баз даних є обов'язковим, якщо ваші дані складніші за пост-модель WordPress, вона буде величезною, і в ній багато метаданих, які будуть шукати.
Формат EAV, який WordPress використовує для своєї постмета, не піддається багатокритеріальному пошуку.
Якщо ви поділите свою мета на багато записів, ви матимете численні записи на одну посаду в мета-таблиці публікації, і пошук будь-якої публікації через мета буде набагато повільніше.
Якщо ви зберігаєте всі метаси, серіалізовані в масиві, і матимуть їх лише як один запис у пост-мета, цього разу ви змушені будете робити лише пошук тексту всередині цього мета, і ви не зможете використовувати оператори порівняння безпосередньо у вашому запиті sql.
Не велика проблема, якщо у вашому плагіні не буде тисячі записів і пов'язаних мета.
Але головна проблема, якщо ваш плагін буде робити щось велике.
Ваша ситуація, ім'я файлу як незалежна запис та 3 записи метаданих, що додаються до цього запису, не здаються такими великими. Ви можете використовувати для цього Wordpress post table та мета-таблицю.
Але, якщо люди будуть багато шукати ці 3 мета, ОСОБЛИВО спільно, то я б рекомендував вам створити окремі таблиці.
При такому форматі лише одна таблиця з одним записом, яка також містить всі метаси, буде добре, і запит буде блискавично.
Між іншим, якщо ви використовуєте таблиці WordPress, а також використовуєте кешування запитів, користувач здійснює пошук ваших даних, з часом кешується і несе менше навантаження. Але це не буде настільки розважливим, як робити окремі столи.
Ви можете завантажити свої файли в медіатеку. Кожен елемент медіатеки зберігається в wp_postsтаблиці. Це означає, що кожен файл може мати метадані. За wp_postmetaдопомогою API метаданих можна зберегти стільки інформації, скільки потрібно для кожного файлу в таблиці .
Чи погана практика створення власної таблиці для плагіна?
Так, погана практика створювати власну таблицю, якщо ви можете замість цього використовувати основну функціональність.
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;
}
}