Если я хочу сохранить настройки для своего плагина, то это довольно просто и прямо.
Теперь я хотел бы сохранить в базе данных немного больше.
Имя файла и 3 других значения, которые применяются только к этому файлу. И есть много файлов с этими значениями. Можно ли сохранить вид подмассивов, используя встроенные методы базы данных? Как я могу удалить и отсортировать их и т. Д.?
Ответы:
Я редко не согласен с другими хорошо осведомленными пользователями, но в этом случае я ничего не могу поделать. На мой взгляд, называть использование неосновных таблиц базы данных плохой практикой как таковой просто неправильно.
Выбор того, использовать ли основные таблицы или добавить свои, зависит от нескольких факторов.
Время выполнения запроса зависит от размера таблицы. Следовательно, если вы планируете хранить значительные объемы данных, отдельная таблица, обслуживающая только этот один тип определенного набора данных, неизбежно будет более эффективным решением.
Если вы храните много регулярных сообщений или CPT вместе с этими конкретными наборами данных, wp_postsа также wp_postmetaможете быстро расти.
Для меня этот выбор в конечном итоге зависит от того, насколько «посты» данные. Должен ли он поддерживать автора, комментарии, исправления, выдержки или тому подобное? Если так, я пойду с CPT и / или основной функциональностью. Если нет, я пойду с отдельными таблицами ради использования ресурсов и эффективности.
Если бы представление Юджина было верным, ни один из существующих хорошо написанных плагинов не добавил бы свои собственные таблицы, что, к счастью, не так.
$wpdbкласса .wp_optionsи принуждение разработчика плагина тщательно учитывать тип создаваемых / хранимых данных - является ли это CPT? это таксономия? это пост мета?Однако для тех случаев использования, когда требуется отдельная таблица БД, обязательно используйте метод, который WordPress предоставляет для добавления вашей пользовательской таблицы в базу данных WordPress , особенно для того, чтобы вы могли воспользоваться мощным $wpdbклассом. Обратите внимание на информацию / предостережения в этих списках записей Кодекса:
Информация о настройке - выбор пользователя, который вводится, когда пользователь впервые настраивает ваш плагин, и не имеет тенденций к большему выходу за его пределы (например, в плагине, связанном с тегами, выбор пользователя в отношении формата облака тегов в боковая панель). Информация о настройках обычно хранится с использованием механизма опций WordPress.
Данные - информация, которая добавляется по мере того, как пользователь продолжает использовать ваш плагин. Обычно это расширенная информация, относящаяся к публикациям, категориям, загрузкам и другим компонентам WordPress (например, в плагине, связанном со статистикой, различных просмотрах страниц, ссылках). и другая статистика, связанная с каждым постом на вашем сайте). Данные могут храниться в отдельной таблице MySQL, которую нужно будет создать. Однако, прежде чем переходить к совершенно новой таблице, подумайте, сработает ли сохранение данных вашего плагина в WordPress Post Meta (также называемые пользовательскими полями). Post Meta является предпочтительным методом; используйте его, когда это возможно / практично.
Таким образом, можно сделать следующие выводы:
$wpdb(использование его с неосновными таблицами подразумевалось в моем ответе, я бы не хотел пропустить этот класс)
Неосновные таблицы базы данных необходимы, если ваши данные более сложны, чем пост-модель WordPress, они будут огромными, и в них будет много метаданных, которые будут искать.
Формат EAV, который WordPress использует для своей мета-записи, не подходит для многокритериального поиска.
Если вы разделите свою мета на множество записей, у вас будет много записей на пост в мета-таблице постов, и поиск любого поста с помощью метасов будет намного медленнее.
Если вы храните все мета-последовательности, сериализованные в массиве, и у вас есть только одна запись в пост-мета, на этот раз вы будете вынуждены выполнять только текстовый поиск внутри этой мета, и вы не сможете использовать операторы сравнения непосредственно в вашем sql-запросе.
Не большая проблема, если ваш плагин не будет иметь тысячи записей и связанных мета.
Но главная проблема, если ваш плагин собирается делать что-то большое.
Ваша ситуация, имя файла в качестве независимой записи и 3 записи метаданных, прикрепленных к этой записи, не кажутся такими уж большими. Для этого вы можете использовать таблицу сообщений WordPress и таблицу метаданных.
НО, если люди собираются много раз искать эти 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;
}
}