Вы должны скептически относиться ко всем, кто говорит, что существует единственный «правильный» путь. Правильный путь зависит от ситуации. Использование инфраструктуры CPT имеет ряд заметных преимуществ:
- Вы получаете пользовательский интерфейс Dashboard бесплатно
- Вы автоматически используете преимущества кэширования WP, включая любые постоянные плагины кэша, которые может использовать установка
- Вы автоматически получаете положительные отзывы, такие как исправления
- Вы получаете доступ к
WP_Queryклассу, что означает, что теоретически вам не нужно писать какой-либо (или, по крайней мере, не так много) SQL с ошибками и уязвимостями и неэффективными SQL
- Если вы планируете распространять плагин или открывать его для разработки с открытым исходным кодом, вы можете обнаружить, что разработчикам удобнее использовать пользовательские типы записей и связанные с ними функции API, чем ваши собственные пользовательские компоненты.
Проблемы с CPT API в основном связаны с тем, что он тесно связан с метафорой «записей» и всеми аспектами этого типа данных, которые сопровождают метафору. Из командной строки MySQL запустите DESCRIBE wp_posts. WP предполагает, что у вашего контента есть заголовок, у него есть (один) автор, что вам нужно только отслеживать дату создания и дату последнего редактирования, что вам понадобится место для неиндексированного post_contentи т. Д. Это работает хорошо для некоторых видов контента, но не обязательно для других. Вы уже указали в направлении некоторых потенциальных проблем:
количество почтовых мета-полей, которые мне понадобятся для моих дополнительных полей на cpt, если я пойду по этому пути, и если это сделает вещи "хитрыми"
Есть два способа дополнить wp_postsсхему через CPT API: постмета и таксономия. Postmeta - это неиндексированные пары ключ-значение, которые отлично подходят для хранения множества разных данных, но совсем не оптимизированы для выполнения сложных поисков. Таксономии несколько более гибки в этом отношении, но вы все равно столкнетесь с множеством потенциально дорогостоящих подзапросов, если у вас будут очень сложные поиски. (В meta_queryи tax_queryаргументы и их классы конструктор запросов очень приятно и удобно, однако.)
Если, как вы предлагаете, вы только должны сделать эти виды «пол сложных реляционных фильтров» в случае отдельных докладов, то эта архитектура , вероятно , хорошо для вас. Когда вы начинаете открывать фильтры для пользователей, чтобы вам приходилось постоянно выполнять множество сложных JOINзапросов и подзапросов, все быстро выходит из-под контроля.
как лучше всего управлять отношениями, особенно если у меня много-много отношений
Отношения «многие ко многим» являются давним камнем преткновения в сообществе разработчиков WP (см. Https://core.trac.wordpress.org/ticket/14513 ). Вы можете подделать его, не используя пользовательские таблицы, сопоставляя элементы таксономии с post_ids (так что, например, вы можете сказать, что «P3 имеет отношение Y к P5», говоря, что P3 имеет тег «Y-P3»), но это сбивает с толку (и неэффективно) очень быстро. Вы также можете рассмотреть возможность создания своей собственной таблицы отношений, которая связывает воедино CPT - вы все равно получите преимущество от CPT и будете создавать только одну таблицу DB. Для хорошо выполненной версии этого метода см. Плагин Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Итак, в конце концов, вы должны решить, основываясь на:
- Тип (ы) данных, которые вы будете хранить - насколько они «постят»
- Виды запросов, которые будут необходимы - насколько сложными они будут
- Масштаб - насколько сложна ваша желаемая схема, сколько всего объектов у вас будет, и сколько пользователей вы ожидаете
Если ответы такие: очень постовые, не слишком сложные и не должны масштабироваться сверхвысокими, используйте CPT. В противном случае рассмотрим ваши собственные таблицы.
meta_queryarg тоже здорово!