Dovresti essere scettico nei confronti di chiunque affermi che esiste un solo modo "giusto". Il modo giusto dipende dalla situazione. L'uso dell'infrastruttura CPT ha una serie di notevoli vantaggi:
- Ottieni l'interfaccia utente Dashboard gratuitamente
- Sfrutta automaticamente la memorizzazione nella cache di WP, inclusi eventuali plug-in di cache persistenti che l'installazione potrebbe utilizzare
- Ottieni automaticamente chicche come le revisioni post
- Ottieni l'accesso alla
WP_Queryclasse, il che significa che, in teoria, non devi scrivere alcun SQL (o almeno non molto) probabile che sia buggy-e-vulnerabile-e-inefficiente
- Se stai pensando di distribuire il plug-in o aprirlo per lo sviluppo open source, potresti scoprire che gli sviluppatori sono più a loro agio nell'utilizzare i tipi di post personalizzati e le funzioni API associate rispetto ai tuoi contenuti personalizzati
I problemi con l'API CPT derivano principalmente dal fatto che è fortemente sposato con la metafora dei "post" e con tutti gli aspetti di quel tipo di dati che accompagnano la metafora. Dalla riga di comando di MySQL, esegui DESCRIBE wp_posts. WP presume che il tuo contenuto abbia un titolo, che abbia un (singolo) autore, che devi solo tenere traccia della data di creazione e della data dell'ultima modifica, che avrai bisogno di spazio per un non indicizzato post_content, ecc. Funziona bene per alcuni tipi di contenuti, ma non necessariamente per altri. Hai già indicato la direzione di alcuni potenziali problemi:
il numero di meta-campi post che mi serviranno per i miei campi extra per cpt se seguo quella strada e se ciò renderà le cose "difficili"
Esistono due modi per aumentare lo wp_postsschema tramite l'API CPT: postmeta e tassonomie. Postmeta è coppie chiave-valore non indicizzate, il che è ottimo per archiviare un sacco di dati vari, ma per nulla ottimizzato per fare ricerche complesse. Le tassonomie sono in qualche modo più flessibili in questo senso, ma dovrai comunque affrontare molte sottoquery potenzialmente costose se hai ricerche molto complesse. (I meta_querye le tax_queryargomentazioni e le loro classi costruttore di query sono molto bello e pratico, però.)
Se, come suggerisci, hai solo bisogno di fare questo tipo di "filtri relazionali semi complessi" nel caso di report occasionali, allora questa architettura è probabilmente OK per te. È quando inizi a esporre i filtri agli utenti, in modo da dover eseguire molte JOINs e sottoquery complesse per tutto il tempo, che le cose sfuggono di mano rapidamente.
come gestire al meglio le relazioni, soprattutto se ho molte o molte relazioni
Le relazioni molti-a-molti sono un punto critico di lunga data nella comunità degli sviluppatori WP (vedi https://core.trac.wordpress.org/ticket/14513 ). Puoi simularlo senza usare le tabelle personalizzate mappando gli elementi della tassonomia su post_ids (in modo che, ad esempio, puoi dire che 'P3 ha la relazione da Y a P5' dicendo che P3 ha il tag 'Y-P3') ma questo diventa confuso (e inefficiente) molto rapidamente. Puoi anche prendere in considerazione la possibilità di creare la tua tabella delle relazioni che collega insieme i CPT: otterrai comunque il vantaggio dei CPT e creerai solo una singola tabella DB. Per una versione ben eseguita di questo metodo, consultare il plugin Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Quindi, alla fine, dovresti decidere in base a:
- Il tipo (i) di dati che memorizzerai - come "post" sono
- Il tipo di query che saranno richieste - quanto saranno complesse
- Scala: quanto è complesso lo schema desiderato, quanti oggetti totali avrai e quanti utenti prevedi
Se le risposte sono: molto posty, non troppo complesse e non devono essere ridimensionate in modo enorme, vai con i CPT. Altrimenti considera i tuoi tavoli.