Ви повинні скептично ставитися до тих, хто каже, що існує єдиний "правильний" шлях. Правильний шлях залежить від ситуації. Використання інфраструктури CPT має ряд помітних переваг:
- Ви отримуєте інтерфейс інформаційної панелі безкоштовно
- Ви автоматично скористаєтеся кеш-пам’яттю WP, включаючи будь-які стійкі додатки кешу, які може використовуватись установка
- Ви автоматично отримуєте смаколики, як публікації після публікації
- Ви отримуєте доступ до
WP_Queryкласу, а це означає, що теоретично вам не потрібно писати жодного (або принаймні не багато) SQL, що може бути помилковим, і вразливим, і неефективним
- Якщо ви плануєте розповсюджувати плагін або відкривати його для розробки з відкритим кодом, ви можете виявити, що розробникам зручніше користуватися спеціальними типами публікацій та пов'язаними з ними функціями API, ніж ваші власні спеціальні речі
Проблеми з API CPT здебільшого випливають з того, що він дуже одружений з метафорою "постів", а також з усіма аспектами цього типу даних, що поєднуються з метафорою. З командного рядка MySQL запустіть DESCRIBE wp_posts. WP припускає, що ваш вміст має заголовок, що у нього є (один) автор, що вам потрібно лише відслідковувати створену дату та дату останнього редагування, що вам знадобиться місце для невкладених даних post_contentтощо. Це працює добре для деяких видів вмісту, але не обов'язково для інших. Ви вже вказали на можливі проблеми:
кількість метаполів публікації, які мені знадобляться для моїх додаткових полів за копію, якщо я пройду цим маршрутом, і якщо це зробить речі "складними"
Існує два способи розширення wp_postsсхеми через API CPT: постмета та таксономії. Postmeta - це недекларовані пари ключів і значень, що чудово підходить для зберігання безлічі різних даних, але зовсім не оптимізовано для здійснення складних пошукових запитів. Таксономії є дещо гнучкішими в цьому плані, але ви все ще зіткнетеся з великою кількістю потенційно дорогих запитів, якщо у вас дуже складні пошуки. (Хоча meta_queryі tax_queryаргументи, і їхні конструктори запитів дуже хороші та зручні.)
Якщо, як ви пропонуєте, ви тільки повинні зробити ці види «підлогу складних реляційних фільтрів» в разі окремих доповідей, то ця архітектура , ймовірно , добре для вас. Коли ви починаєте виставляти фільтри користувачам, так що вам доведеться JOINвесь час запускати багато складних s і підзапитів, це швидко виходить з рук.
як найкраще керувати стосунками, особливо якщо у мене багато-багато стосунків
Відносини «багато до багатьох» є давньою крапкою у спільноті розробників WP (див. Https://core.trac.wordpress.org/ticket/14513 ). Ви можете підробити це без використання спеціальних таблиць, зіставивши елементи таксономії на post_ids (так, наприклад, ви можете сказати, що "P3 має відношення Y до P5", сказавши, що P3 має тег "Y-P3"), але це стає заплутаним (і неефективно) дуже швидко. Ви також можете розглянути можливість створення власної таблиці відносин, яка поєднує спільно CPT - ви все одно отримаєте перевагу CPT та створюєте лише одну таблицю БД. Про добре виконану версію цього методу див. У плагіні Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Отже, врешті-решт, ви повинні вирішити, виходячи з:
- Види даних, які ви будете зберігати - як вони "розміщують"
- Види запитів, які будуть потрібні - наскільки вони будуть складними
- Масштаб - наскільки складною є ваша бажана схема, скільки всього об’єктів у вас буде і скільки користувачів ви очікуєте
Якщо відповіді такі: Дуже привабливий, не надто складний і не потрібно масштабувати надмірно великі, займіться CPT. В іншому випадку розгляньте власні таблиці.