Неплохая практика создания собственной таблицы для плагина?

Если я хочу сохранить настройки для своего плагина, то это довольно легко и прямо.

Теперь я хотел бы сохранить в базе данных немного больше.

Имя файла и 3 других значения, которые относятся только к этому файлу. И есть много файлов с этими значениями. Возможно ли сохранить некоторые подмассивы с использованием встроенных методов базы данных? Как я могу удалить и отсортировать их и т. Д.?

Solutions Collecting From Web of "Неплохая практика создания собственной таблицы для плагина?"

Я редко соглашаюсь с другими знающими пользователями, но в этом случае я не могу с этим поделать. На мой взгляд, использование нестандартных таблиц базы данных неверно практикуется просто неправильно.

Выбор того, следует ли делать с основными таблицами или добавлять свои собственные, зависит от нескольких факторов.

Время выполнения запроса зависит от размера таблицы. Следовательно, если вы планируете хранить значительные объемы данных, отдельная таблица, обслуживающая только этот тип конкретных наборов данных, неизбежно будет более эффективным решением.

Если вы храните много обычных сообщений или CPT вместе с этими конкретными наборами данных, wp_posts а также wp_postmeta могут быстро развиваться.

Для меня этот выбор в конечном счете зависит от того, как «постить» данные. Должен ли он поддерживать автора, комментарии, ревизии, выдержки или тому подобное? Если это так, я пойду с CPT и / или базовыми функциями. Если нет, я поеду с отдельными таблицами ради использования ресурсов и эффективности.

Если бы концепция Юджина была правильной, ни один из существующих хорошо написанных плагинов не добавил бы свои собственные таблицы, к счастью, это не так.

Использование WP базовых таблиц БД является наилучшей практикой

  1. Использование базовых таблиц базы данных делает ваши данные более переносимыми и проще в резервном копировании, так как он будет обрабатываться основным экспортером / импортером, а также множеством резервных плагинов
  2. Использование базовых таблиц БД делает ваши данные более легкими и безопасными для управления , поскольку у вас будет более интуитивный доступ к различным функциям WordPress, связанным с запросом, добавлением, изменением, удалением и дезинфекцией данных БД, особенно через очень мощный класс $wpdb .
  3. Использование базовых таблиц БД поощряет / облегчает передовую практику классификации и хранения данных , таких как сохранение параметров плагина в виде массива в одной строке в wp_options и принуждение разработчика плагина тщательно рассмотреть тип создаваемых / сохраненных данных – это CPT? это таксономия? это сообщение мета?
  4. При использовании базовых таблиц базы данных ваш плагин с меньшей вероятностью оставит позади себя .

WordPress предоставляет средства для плагинов для добавления таблиц в свою базу данных

Однако для тех случаев, когда требуется отдельная таблица БД, обязательно используйте метод, который WordPress предоставляет для добавления вашей пользовательской таблицы в базу данных WordPress , особенно для того, чтобы вы могли использовать мощный класс $wpdb . Обратите внимание на информацию / предостережения в этих списках ввода Codex:

  • Информация о настройке – пользовательские варианты, которые вводятся, когда пользователь сначала настраивает ваш плагин, и не имеют тенденций к значительному увеличению (например, в плагине, связанном с тегом, выборе пользователя в отношении формата облака тегов в боковая панель). Информация о настройке обычно хранится с использованием механизма опций WordPress.

  • Данные – информация, добавленная пользователем, продолжает использовать ваш плагин, который обычно расширяет информацию, связанную с сообщениями, категориями, загрузками и другими компонентами WordPress (например, в подключенном к статистике плагине, различных просмотрах страниц, реферерах , и другие статистические данные, связанные с каждым сообщением на вашем сайте). Данные могут храниться в отдельной таблице MySQL, которая должна быть создана. Однако, прежде чем переходить на новую таблицу, подумайте, будет ли сохранено сохранение данных вашего плагина в WordPress Post Meta (aka Custom Fields). Post Meta является предпочтительным методом; используйте его, когда это возможно / практично.

Таким образом, мы можем заключить следующее:

  1. Хранение данных (настройка или создание пользователями) в основных таблицах WP – лучшая практика
  2. Существуют действующие прецеденты для создания пользовательских таблиц БД; поэтому создание пользовательских таблиц БД нельзя рассматривать как неотъемлемую плохую практику
  3. При создании пользовательских таблиц базы данных WordPress обеспечивает передовую практику

Таблицы без базовой базы данных являются обязательными, если ваши данные более сложны, чем модель WordPress post, она будет огромной, и в ней будет много метаданных, которые будут найдены.

Формат EAV, используемый WordPress для метаданных, не поддается многокритериальному поиску.

Если вы разделите свою мета на многие записи, у вас будет много записей за сообщение в метатете сообщений, а поиск любой почты через мета-файлы будет намного медленнее.

Если вы сохраните все метасы, сериализованные в массиве, и сделайте это как только одну запись в метатете post, на этот раз вам придется делать только текстовые запросы внутри этой мета, и вы не сможете использовать операторы сравнения непосредственно в вашем sql-запросе.

Не большая проблема, если ваш плагин не будет иметь тысячи записей и связанных мета.

Но серьезная проблема, если ваш плагин будет делать что-то большое.


Ваша ситуация, имя файла как независимая запись и 3 записи метаданных, прикрепленных к этой записи, не кажутся такими большими. Для этого вы можете использовать таблицу сообщений WordPress и мета-таблицу.

НО, если люди собираются много искать эти 3 метаса, ОСОБЕННО в сочетании, то я бы рекомендовал вам создать отдельные таблицы.

В этом формате только одна таблица с одной записью, которая также содержит все мета, будет в порядке, и будет запрашивать молниеносно.

Кстати, если вы используете таблицы WordPress, а также используете кеширование запросов, пользователь ищет ваши данные, которые будут кэшироваться с течением времени и несут меньше нагрузки. Но это не было бы настолько осмотрительным, как отдельные таблицы.

Вы можете загружать файлы в медиа-библиотеку. Каждый элемент в медиа-библиотеке wp_posts таблицу 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; } } 

  • Имя класса оригинальное, переименуйте его по своему усмотрению.
  • В функциях php add: add_action ('init', array ('TMM', 'register'), 1);
  • И добавить для ajax: add_action ('wp_ajax_change_options', array ('TMM', 'change_options'));
  • Чтобы получить опцию, где вам нужно использовать это (например): $ logo_img = TMM :: get_option ('logo_img');
  • Используйте его, чтобы сохранить свои варианты с помощью собственных методов WordPress