Powinieneś być sceptyczny wobec każdego, kto twierdzi, że istnieje jeden „właściwy” sposób. Właściwy sposób zależy od sytuacji. Korzystanie z infrastruktury CPT ma wiele znaczących zalet:
- Uzyskujesz interfejs Dashboard za darmo
- Automatycznie korzystasz z buforowania WP, w tym wszelkich trwałych wtyczek pamięci podręcznej, z których może korzystać instalacja
- Automatycznie otrzymujesz gadżety, takie jak wersje postów
- Uzyskujesz dostęp do
WP_Queryklasy, co oznacza, że teoretycznie nie musisz pisać żadnego (lub przynajmniej niewiele) prawdopodobnie SQL-a-buggy-i-wrażliwego-i-nieefektywnego SQL
- Jeśli planujesz dystrybuować wtyczkę lub otwierać ją w celu opracowania oprogramowania typu open source, może się okazać, że programiści czują się bardziej komfortowo, korzystając z niestandardowych typów postów i powiązanych funkcji API niż z własnych niestandardowych rzeczy
Problemy z interfejsem CPT API wynikają głównie z faktu, że jest on ściśle powiązany z metaforą „postów” i wszystkimi aspektami tego typu danych, które towarzyszą metaforze. Z wiersza polecenia MySQL uruchom DESCRIBE wp_posts. WP zakłada, że twoja treść ma tytuł, że ma (jednego) autora, że musisz tylko śledzić datę utworzenia i datę ostatniej edycji, że potrzebujesz miejsca na nieindeksowane post_contentitp. To działa dobrze dla niektórych rodzajów treści, ale niekoniecznie dla innych. Wskazałeś już pewne potencjalne problemy:
liczba metapól postów, których potrzebuję dla dodatkowych pól na cpt, jeśli wybiorę tę trasę, a jeśli to sprawi, że będzie to „trudne”
Istnieją dwa sposoby rozszerzenia wp_postsschematu za pomocą interfejsu CPT API: postmeta i taksonomie. Postmeta to nieindeksowane pary klucz-wartość, które świetnie nadają się do przechowywania wielu różnych danych, ale nie są zoptymalizowane do wykonywania skomplikowanych wyszukiwań. Taksonomie są nieco bardziej elastyczne pod tym względem, ale nadal będziesz mieć do czynienia z wieloma potencjalnie kosztownymi podkwerendami, jeśli masz bardzo złożone wyszukiwania. (Te meta_queryi tax_queryargumenty i ich klasy konstruktora zapytań są bardzo ładne i wygodne, choć.)
Jeśli, jak sugerujesz, potrzebujesz tylko tego rodzaju „częściowo złożonych filtrów relacyjnych” w przypadku sporadycznych raportów, ta architektura prawdopodobnie jest dla Ciebie odpowiednia. To właśnie wtedy, gdy zaczynasz udostępniać filtry użytkownikom, abyś musiał JOINcały czas uruchamiać wiele złożonych zapytań i podkwerend, szybko wymyka się spod kontroli.
jak najlepiej zarządzać relacjami, szczególnie jeśli mam wiele do wielu relacji
Relacje wiele do wielu są od dawna utrzymujące się w społeczności deweloperów WP (patrz https://core.trac.wordpress.org/ticket/14513 ). Możesz go sfałszować bez użycia niestandardowych tabel, mapując elementy taksonomii na post_ids (tak, że np. Możesz powiedzieć, że „P3 ma relację Y do P5”, mówiąc, że P3 ma znacznik „Y-P3”), ale robi się to mylące (i nieefektywne) bardzo szybko. Możesz także rozważyć utworzenie własnej tabeli relacji, która łączy ze sobą CPT - nadal będziesz czerpać korzyści z CPT i tworzysz tylko jedną tabelę DB. Aby uzyskać ładnie wykonaną wersję tej metody, zobacz wtyczkę Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Ostatecznie powinieneś zdecydować na podstawie:
- Rodzaj (-y) danych, które będziesz przechowywać - jak „post” są
- Rodzaje zapytań, które będą wymagane - jak złożone będą
- Skala - jak skomplikowany jest twój pożądany schemat, ile obiektów będziesz mieć i ilu użytkowników spodziewasz się
Jeśli odpowiedzi są następujące: Bardzo posty, niezbyt skomplikowane i nie trzeba skalować super-ogromnych, przejdź do CPT. W przeciwnym razie rozważ własne tabele.