Должен ли я использовать пользовательские типы сообщений или настраиваемые таблицы базы данных для разработки плагинов?

Я довольно новичок в написании плагинов для wordpress, но я уже вскочил в глубокий конец, и я хочу убедиться, что я делаю это «правильно» в своем предстоящем крупном проекте.

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

Я еще не знаю всех моих данных, но будет множество ссылок (или cpts), связанных реляционно. Я получаю «vibe» от своих исследований, что мне следует избегать пользовательских таблиц базы данных, но я не уверен, как определить оптимальное решение.

В частности, меня беспокоят три области:

  • количество почтовых метафилей, которые мне понадобятся для моих дополнительных полей на один cpt, если я пойду по этому маршруту, и если это сделает вещи «сложными»
  • Насколько я могу получить ответы на запросы с использованием полупростых реляционных фильтров для отчетов
  • как лучше управлять отношениями, особенно если у меня есть много разных отношений.

Есть ли «правильный» способ? Спасибо за ваш вклад.

33 голоса | спросил Jeff 4 AMpWed, 04 Apr 2012 03:16:36 +040016Wednesday 2012, 03:16:36

1 ответ


49

Вы должны скептически относиться ко всем, кто говорит, что существует один «правильный» способ. Правильный путь зависит от ситуации. Использование инфраструктуры CPT имеет ряд заметных преимуществ:

  • Вы получаете пользовательский интерфейс Dashboard бесплатно
  • Вы автоматически используете кэширование WP, включая любые постоянные плагины кэша, которые могут быть установлены при установке
  • Вы автоматически получаете положительные результаты, например, после ревизий.
  • Вы получаете доступ к классу WP_Query, что означает, что, теоретически, вам не нужно писать какие-либо (или, по крайней мере, не очень), вероятно, чтобы быть багги- уязвимый и неэффективный SQL
  • Если вы планируете распространять плагин или открывать его для разработки с открытым исходным кодом, вы можете обнаружить, что разработчикам удобнее использовать пользовательские типы сообщений и связанные с ними функции API, чем ваши собственные пользовательские материалы.

Проблемы с API CPT в основном связаны с тем, что он высоко женат на метафоре «сообщений» и всех аспектах этого типа данных, которые приходят вместе с метафорой. В командной строке MySQL запустите DESCRIBE wp_posts. WP предполагает, что ваш контент имеет заголовок, что у него есть (единственный) автор, что вам нужно только отслеживать созданную дату и дату последнего редактирования, что вам потребуется место для неиндексированного post_content и т. д. Это хорошо работает для некоторых видов контента, но не обязательно для других. Вы уже указали на некоторые потенциальные проблемы:

  

количество почтовых метафилей, которые мне понадобятся для моих дополнительных полей на один cpt, если я пойду по этому маршруту, и если это сделает вещи «сложными»

Существует два способа расширения схемы wp_posts через API CPT: postmeta и таксономии. Postmeta - это неиндексированные пары ключ-значение, которые отлично подходят для хранения множества разных данных, но вовсе не оптимизированы для выполнения сложных поисков. Таксономии несколько более гибкие в этом отношении, но вы по-прежнему сталкиваетесь с множеством потенциально дорогостоящих подзапросов, если у вас очень сложный поиск. (meta_query и tax_query аргументы и их классы конструкторов запросов очень приятны и удобны.)

Если, как вы полагаете, вам only нужно делать эти «полуосложные реляционные фильтры» в случае случайных отчетов, то эта архитектура, вероятно, подходит для вас. Это когда вы начинаете подвергать фильтры пользователям, так что вы должны запускать много сложных JOIN s и подзапросов все время, что вещи быстро выходят из строя.

  

как лучше всего управлять отношениями, особенно если у меня много отношений.

Связи Many-to-many являются давней точкой привязки в сообществе WP dev (см. https: //core.trac .wordpress.org /билет /14513 ). Вы можете подделать его без использования пользовательских таблиц путем отображения элементов таксономии на post_ids (так, например, вы можете сказать, что «P3 имеет отношение Y к P5», говоря, что P3 имеет тег «Y-P3»), но это путает (и неэффективно) очень быстро. Вы также можете подумать о создании своей собственной таблицы отношений, которая связывает CPT - вы все равно получите преимущество CPT и только создаете одну таблицу DB. Для хорошо выполненной версии этого метода см. Плагин Posts 2 Posts: https://wordpress.org/расширяющие /плагин /сообщений к сообщениям /

Итак, в конце концов, вы должны решить, основываясь на:

  • Вид (ы) данных, которые вы будете хранить - как «post» y они
  • Виды запросов, которые потребуются - насколько они сложны.
  • Масштаб - насколько сложна ваша желаемая схема, сколько всего объектов вы будете иметь и сколько пользователей вы ожидаете

Если ответы: Очень посты, не слишком сложные, и не нужно масштабировать супер-огромные, идите с CPT. В противном случае рассмотрите свои собственные таблицы.

ответил Boone Gorges 4 AMpWed, 04 Apr 2012 04:21:10 +040021Wednesday 2012, 04:21:10

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132