O modelo de dados do Wordpress
Enviado por Mauro Pichiliani (pichilianiΘuol·com·br):
“Neste artigo apresento uma análise do modelo de dados utilizado no WordPress. Além de analisar o modelo de dados, vou disponibilizar scripts, imagens, e o próprio modelo de dados em outros formatos para aqueles que precisem saber como os dados são armazenados no MySQL quando se utiliza o WordPress. Também comento outros assuntos relacionados ao banco de dados e ao WordPress em si.” [referência: imasters.uol.com.br]
• Publicado por Augusto Campos em
2010-03-02
@brlinuxblog
Feed RSS
Parece um bom exemplo de como não fazer um modelo.
Chave estrangeiras pra que né ?
Heranças do tempo que o MySQL nem tinha isso.
Conheço muitos sistemas em vários tipos de banco de dados que não possuem FK. Muita gente acha que FK é frescura.
Fora as PK’s não existe mais nenhum índice sequer no banco.
E depois ainda dizem que não dão suporte à bibliotecas de bancos decentes como ADODB ou PDO por conta de performance.
Bom, pelo menos o artigo pode se prestar muito bem ao que se propõe, de ser um guia para quem entende poder aplicar suas próprias otimizações.
eu chuto que uma boa parte de quem gerencia, não estou falando de designers ou blogueiros, o wp nunca foi lá e viu como é a modelagem dos dados, idem drupal, joomla e outros. Porisso o artigo é tão oportuno.
O artigo também joga uma luz na questão dos plugins que geram muitas requisições ao banco, como os de contagem de comentários e outros, antes se colocava a culpa nos plugins, na verdadae é a construção da modelagem do banco.
Apesar disso comparar o modelo de dados do WP com um modelo mais tradicional é complicado pois não estamos tratando de registros com zilhões de atributos. outro detalhe é que no MySQL, alguns recursos como fulltextsearch só estão disponiveis para myisam.
@Garcia
“Conheço muitos sistemas em vários tipos de banco de dados que não possuem FK. Muita gente acha que FK é frescura.”
Essa “gente acha”. O “achar” diz tudo.
A questão é que FK, embora realmente seja um recurso inigualável para manter integridade, traz muita penalidade em performance.
Se integridade é tudo, então pq quase ninguém usa o CHECK no Oracle, enquanto LIST/ENUM é comum no MySQL? Entendeu aqui a falta de coerência?
Eu não disse que integridade é tudo, mas é importante.
Eu não uso Check no postgres porque geralmente não preciso. Mas chave estrangeira ? Por favor, é básico.
Se existe um SGBD e com FK ele faz a performance cair absurdamente, é claro para mim que o SGBD ainda não está maduro.
Pois, repetindo, é um recurso básico.
O que acontece é que programadores não gostam de precisar sair da zona de conforto e ter de ler UMA página para entender como funcionam recursos como FK.
Preferem implementar tudo no código. Geralmente de forma muito mais ineficiente, afinal, o programador não vai conseguir buscar e processar dados mais rápido que o sistema criado exclusivamente para isso, o SGBD.
FK é básico de banco de dados. O MySQL, por ser popular, e não ter o recurso por muito tempo, popularizou a idéia de supérfluo. Não é.
Se “Code is poetry”, pra quê FK? FK-se os DBAs.
FK é coisa de DBA ? ouch.