Должен ли я использовать пользовательские типы записей или пользовательские таблицы базы данных для разработки плагинов?
Я довольно новичок в написании плагинов wordpress, но я уже глубоко продвинулся и хочу убедиться, что делаю это "правильно" в своем предстоящем большом проекте.
Я собираюсь сильно расширить wordpress в довольно большое веб-приложение и хочу, чтобы мои структуры данных были как можно более родными, чтобы полагаться на фреймворк wordpress, но я не знаю, лучше ли создавать собственные таблицы пользовательских баз данных или пытаться использовать пользовательские типы записей.
Я не пока я знаю все свои данные, но будет несколько таблиц (или cpt), связанных между собой. Из моих исследований я получаю "ощущение", что мне следует избегать пользовательских таблиц базы данных, но я не уверен, как определить наилучшее решение.
В частности, меня беспокоят три области:
- количество метаполей сообщений, которые мне понадобятся для моих дополнительных полей на cpt, если я пойду по этому маршруту, и если это сделает вещи "сложными"
- насколько хорошо я могу возвращать запросы, используя полусложные реляционные фильтры для отчетов
- как лучше всего управлять отношениями, особенно если у меня много-много отношений
Существует ли "правильный" путь? Спасибо за ваш вклад.
1 answers
Вы должны скептически относиться к любому, кто говорит, что существует единственный "правильный" путь. Правильный путь зависит от ситуации. Использование инфраструктуры CPT имеет ряд заметных преимуществ:
- Вы получаете пользовательский интерфейс панели мониторинга бесплатно
- Вы автоматически используете преимущества кэширования 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 и их классы конструкторов запросов очень хороши и удобны.)
Если, как вы предполагаете, вам только нужно выполнять такие "полукомплексные реляционные фильтры" в случае случайных отчетов, то эта архитектура, вероятно, подходит для вас. Именно тогда, когда вы начинаете предоставлять фильтры пользователям, так что вам все время приходится запускать множество сложных JOIN и подзапросов, ситуация быстро выходит из-под контроля.
Как чтобы лучше управлять отношениями, особенно если у меня много-много отношений
Отношения "многие ко многим" являются давним камнем преткновения в сообществе разработчиков WP (см. https://core.trac.wordpress.org/ticket/14513 ). Вы можете подделать это без использования пользовательских таблиц, сопоставив элементы таксономии с post_ids (так, например, вы можете сказать, что "P3 имеет отношение Y к P5", сказав, что у P3 есть тег "Y-P3"), но это очень быстро запутывает (и неэффективно). Вы также можете подумайте о создании собственной таблицы взаимосвязей, которая связывает CPTS - вы все равно получите преимущества CPTS и создадите только одну таблицу БД. Для хорошо выполненной версии этого метода см. Плагин Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Итак, в конце концов, вы должны принять решение, основываясь на:
- Вид(ы) данных, которые вы будете хранить - как они "публикуются"
- Какие типы запросов потребуются - насколько сложные будут ли они
- Масштаб - насколько сложна ваша желаемая схема, сколько всего у вас будет объектов и сколько пользователей вы ожидаете
Если ответы таковы: Очень сложный, не слишком сложный, и не нужно масштабировать супер-огромные, используйте CPTS. В противном случае рассмотрите свои собственные таблицы.