Você deve ser cético em relação a quem disser que existe um único caminho "certo". O caminho certo depende da situação. O uso da infraestrutura de CPT possui vários benefícios notáveis:
- Você obtém a interface do usuário do painel gratuitamente
- Você tira vantagem automaticamente do cache do WP, incluindo quaisquer plugins de cache persistentes que a instalação possa estar usando
- Você recebe brindes automaticamente, como revisões posteriores
- Você obtém acesso à
WP_Queryclasse, o que significa que, em teoria, você não precisa escrever nenhum (ou pelo menos não muito) provável SQL de buggy e vulnerável e ineficiente
- Se você está planejando distribuir o plug-in ou abri-lo para o desenvolvimento de código-fonte aberto, talvez ache que os desenvolvedores estão mais confortáveis usando tipos de postagem personalizados e as funções de API associadas do que seus próprios itens personalizados
Os problemas com a API do CPT decorrem principalmente do fato de ela ser altamente casada com a metáfora de 'postagens' e de todos os aspectos desse tipo de dados que acompanham a metáfora. Na linha de comando do MySQL, execute DESCRIBE wp_posts. O WP assume que seu conteúdo tem um título, que possui um (único) autor, que você só precisa acompanhar a data de criação e a data da última edição, que precisará de espaço para um código não indexado post_contentetc. Isso funciona bem para alguns tipos de conteúdo, mas não necessariamente para outros. Você já apontou na direção de alguns problemas em potencial:
o número de metafields pós necessários para meus campos extras por cpt se eu seguir esse caminho e se isso tornar as coisas "complicadas"
Existem duas maneiras de aumentar o wp_postsesquema por meio da API do CPT: pós-meta e taxonomias. O Postmeta é um par de valores-chave não indexados, o que é ótimo para armazenar vários dados diversos, mas nada otimizado para pesquisas complexas. As taxonomias são um pouco mais flexíveis nesse aspecto, mas você ainda enfrentará muitas subconsultas potencialmente caras se tiver pesquisas muito complexas. (As meta_querye tax_queryargumentos e suas classes construtor de consulta são muito agradável e acessível, no entanto.)
Se, como você sugere, você só precisa fazer esses tipos de "filtros relacionais semi-complexos" no caso de relatórios ocasionais, então essa arquitetura provavelmente é boa para você. É quando você começa a expor os filtros para os usuários, para que você tenha que executar muitas JOINsubconsultas e complexas o tempo todo, que as coisas saem do controle rapidamente.
como gerenciar melhor os relacionamentos, especialmente se eu tiver muitos ou muitos relacionamentos
Os relacionamentos muitos para muitos são um ponto de discórdia de longa data na comunidade de desenvolvedores do WP (consulte https://core.trac.wordpress.org/ticket/14513 ). Você pode falsificá-lo sem usar tabelas personalizadas mapeando itens de taxonomia para post_ids (para que, por exemplo, você possa dizer que 'P3 tem a relação Y com P5' dizendo que P3 tem a tag 'Y-P3'), mas isso fica confuso (e ineficiente) muito rapidamente. Você também pode considerar criar sua própria tabela de relacionamentos que vincula os CPTs - você ainda obteria o benefício dos CPTs e criaria apenas uma única tabela de banco de dados. Para uma versão bem executada desse método, consulte o plug-in Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Portanto, no final, você deve decidir com base em:
- O (s) tipo (s) de dados que você estará armazenando - como são "postados" y
- Os tipos de consultas que serão necessárias - quão complexas elas serão
- Escala - quão complexo é o esquema desejado, quantos objetos totais você terá e quantos usuários você antecipa
Se as respostas forem: Muito finas, não muito complexas e não precisam ser muito grandes, use CPTs. Caso contrário, considere suas próprias tabelas.