Devo usar tipos de postagem personalizados ou tabelas de banco de dados personalizadas para o desenvolvimento de plug-ins?

33

Sou relativamente novo em escrever plugins para wordpress, mas já entrei no fundo do poço e quero ter certeza de que estou fazendo "certo" em meu próximo grande projeto.

Vou estender bastante o wordpress para um aplicativo da web bem grande e quero manter minhas estruturas de dados o mais nativas possível para contar com o framework wordpress, mas não sei se é melhor criar meu próprio tabelas de banco de dados personalizadas ou tente usar tipos de postagem personalizados.

Ainda não conheço todos os meus dados, mas haverá um número de tabelas (ou cpts) vinculadas de forma relacional. Eu recebo a "vibração" da minha pesquisa que eu deveria evitar tabelas de banco de dados personalizadas, mas não sei como determinar a melhor solução.

Especificamente, estou preocupado com três áreas:

  • o número de metafields de postagem que eu precisarei para meus campos extras por cpt se eu for para esse caminho, e se isso tornar as coisas "complicadas"
  • como posso recuperar consultas usando filtros relacionais semi-complexos para relatórios
  • como gerenciar melhor os relacionamentos, especialmente se tiver muitos ou muitos relacionamentos

Existe um caminho "certo"? Obrigado pela sua contribuição.

    
por Jeff 04.04.2012 / 01:16
fonte

1 resposta

51

Você deve ser cético em relação a quem diz que há um único caminho "certo". O caminho certo depende da situação. A utilização da infraestrutura do CPT tem vários benefícios notáveis:

  • Você recebe a interface do painel de graça
  • Você aproveita automaticamente o cache do WP, incluindo qualquer plug-in de cache persistente que a instalação possa estar usando
  • Você recebe automaticamente guloseimas como revisões posteriores
  • Você obtém acesso à classe WP_Query , o que significa que, em teoria, você não precisa escrever nenhum (ou pelo menos não muito) provável de ser buggy e vulnerável e ineficiente SQL
  • Se você estiver planejando distribuir o plug-in ou abri-lo para o desenvolvimento de código-fonte aberto, poderá descobrir que os desenvolvedores se sentem mais confortáveis usando tipos de postagem personalizados e funções da API associadas a seus próprios recursos personalizados
Os problemas com a CPT API decorrem principalmente do fato de que ela é altamente casada com a metáfora de posts, e todos os aspectos desse tipo de dados que vêm junto com a metáfora. Na linha de comando do MySQL, execute DESCRIBE wp_posts . WP assume que o seu conteúdo tem um título, que tem um autor (single), que você só precisa manter o controle da data de criação eo último editado data, que você vai precisar de espaço para umpost_content unindexed%, etc Isso funciona bem para alguns tipos de conteúdo, mas não necessariamente para outros. Você já gesticulou na direção de alguns possíveis problemas:

  

o número de metafields de postagem que eu precisarei para meus campos extras por cpt se eu for por esse caminho, e se isso tornar as coisas "complicadas"

Existem duas maneiras de aumentar o esquema wp_posts por meio da API do CPT: postmeta e taxonomias. Postmeta são pares de valor-chave não indexados, o que é ótimo para armazenar vários dados diversos, mas não otimizado para fazer pesquisas complexas. As taxonomias são um pouco mais flexíveis a esse respeito, mas você ainda terá muitas subconsultas potencialmente caras se tiver pesquisas muito complexas. (Os argumentos meta_query e tax_query e suas classes construtoras de consulta são muito bons e úteis, no entanto.)

Se, como você sugere, você somente precisar fazer esses tipos de "filtros relacionais semi-complexos" no caso de relatórios ocasionais, então esta arquitetura provavelmente está correta para você. É quando você começa a expor os filtros aos usuários, para que você precise executar muitas JOIN s e subconsultas complexas o tempo todo, e que as coisas saiam do controle rapidamente.

  

como gerenciar melhor os relacionamentos, especialmente se eu tiver muitos ou muitos relacionamentos

Relacionamentos muitos-para-muitos são um ponto persistente de longa data na comunidade de desenvolvedores do WP (consulte enlace ). Você pode fingir-lo sem usar tabelas personalizadas por itens mapeamento de taxonomia para post_ids (de modo que, por exemplo, você pode dizer que 'P3 tem a relação Y para 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 vincule CPTs - você ainda obterá o benefício de CPTs e estará criando apenas uma única tabela de banco de dados. Para uma versão bem-executado deste método, consulte os Posts 2 Posts plugin: enlace

Então, no final, você deve decidir com base em:

  • O (s) tipo (s) de dados que você irá armazenar - como "post" y eles são
  • Os tipos de consultas que serão necessárias - quão complexas elas serão
  • Escala: quão complexo é o esquema desejado, quantos objetos você tem e quantos usuários você prevê

Se as respostas forem: muito posty, não muito complexas e não precisam ser muito grandes, use os CPTs. Caso contrário, considere suas próprias tabelas.

    
por Boone Gorges 04.04.2012 / 02:21
fonte