Статьи

Стандарты кодирования WordPress: запросы к базе данных и форматирование запросов SQL

Декабрь 20, 2018

Помимо резюме, которое мы собираемся представить в качестве последней статьи в этой серии, это последнее объяснение стандартов кодирования WordPress, которые мы собираемся охватить в этой серии.

Мы собираемся рассказать о нюансах запросов к базе данных и о том, как форматировать SQL в контексте вашего кода.

Конечно, это не обошлось бы без собственного набора предостережений: вообще говоря, уже есть API, которые могут помешать нам писать SQL самостоятельно; тем не менее, эти API не учитывают каждый случай, который нам действительно нужен.

В конце концов, как разработчики, реализующие API, могут точно знать, что и как мы собираемся создать?

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

Запросы к базе данных в WordPress

Как уже упоминалось во введении к этой статье, существует ряд API, которые позволяют нам создавать собственные запросы без необходимости написания SQL.

Причина, по которой важно познакомиться и изучить эти API, заключается в том, что написанный вами код будет написан поверх уровня абстракции, обеспечиваемого WordPress, чтобы убедиться, что запросы максимально оптимизированы (учитывая текущую версию) ,

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

Если схема таблицы изменится, параметры будут отображаться в различных разделах SQL и т. Д., Вам не нужно об этом беспокоиться, потому что API позаботится об этом за вас.

Что такое API запросов?

Так что же такое API запросов, которые определяет WordPress?

  • WP_Query предназначен для запроса информации о любом типе поста и связанных с ним WP_Query , категориях, таксономиях, типах, статусах и т. Д.
  • WP_User_Query предназначен для использования, когда нам нужно извлечь информацию из таблицы пользователя и таблицы usermeta. Это также позволяет нам работать с ролями, настраиваемыми полями и многим другим.

Существуют также другие методы WordPress API, которые позволяют действительно легко получать данные из различных таблиц базы данных, некоторые из которых даже не требуют значительного количества аргументов:

  • get_post_meta извлекает метаданные, связанные с данным идентификатором записи. Он может извлечь все метаданные или значение для определенного ключа.
  • get_comment_meta извлекает метаданные, связанные с данным идентификатором комментария. Он может извлечь все метаданные или значение для определенного ключа.
  • get_user_meta извлекает метаданные, связанные с данным идентификатором пользователя (вы начинаете видеть тему здесь?). Он может извлечь все метаданные или значение для определенного ключа.

Обратите внимание, что цель этой статьи не в том, чтобы глубоко погрузиться в каждый из этих API (и их больше ), а лишь в том, чтобы сделать их известными тем из вас, кто их ранее не использовал, и дать краткое определение того, когда они могут быть использованы.

В конечном счете, это API, которые вы должны изучить прежде, чем писать свой собственный SQL. Для чего это стоит, я говорю из опыта здесь: были времена, когда я писал код (или даже сообщения в блоге), которые были взломаны, потому что они не использовали лучшие практики для запросов к базе данных.

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

Все о $wpdb

Это приводит нас к $wpdb . По сути, $wpdb — это объект, доступный в WordPress, который позволяет нам напрямую взаимодействовать с базой данных. Это означает, что мы можем написать сырой SQL и выполнить его для основной базы данных.

Кроме того, мы можем выбрать способ возврата данных: массивы, объекты, иногда отдельные значения и т. Д. Фактически объект предлагает возможность выполнять следующие функции:

  • SELECT переменные, строки, столбцы и общие результаты
  • INSERT строки
  • UPDATE существующие строки

Возможно, самой большой проблемой при внедрении сырого SQL в ваш проект является то, что вы открываете свой проект для возможного злонамеренного поведения. Хотя это можно сделать для любой логики базы данных, правда заключается в том, что API должны хорошо защищать нас от всего этого.

Вообще говоря, они делают.

Но и $wpdb от этого не освобождается. Существуют конкретные способы взаимодействия с базой данных, чтобы вы могли защитить свои запросы от внедрения SQL.

Чтобы подтвердить точку зрения из стандартов кодирования:

Если вам нужно прикоснуться к базе данных, свяжитесь с некоторыми разработчиками, отправив сообщение в список рассылки wp-hackers. Они могут подумать о создании функции для следующей версии WordPress, чтобы охватить функции, которые вы хотели.

Итак, короче говоря, если API не соответствует тому, что вам нужно, то $wpdb может быть вашим лучшим вариантом, но я рекомендую использовать его только в том случае, если вы исчерпали остальные параметры.

Вывод

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

Чтобы завершить этот конкретный пост, самое важное, что я хочу, чтобы у всех было:

  1. Проверьте API перед написанием встроенного SQL. Даже несмотря на то, что написание прямых SQL-запросов может быть самым простым , особенно для тех, кто работает с системами баз данных, не поддавайтесь! Сначала проверьте документацию по API.
  2. Если вы не можете найти функцию API для вашей работы, напишите SQL. Если вы должны написать SQL, убедитесь, что вы учитываете все необходимое: как вы хотите, чтобы ваши данные возвращались, вы правильно подготовили свои запросы и правильно обрабатываете данные, когда они возвращаются.

Если вы это сделаете, то ваши базы должны быть покрыты.

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

38
Share: