uma desempenho aceitavel.Sem entrar em uma discussao mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor desempenho que o InnoDB, porem este ultimo possui suporte a transacoes, integridade e outros recursos que o MyISAM nao possui.A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas nao e mantido pelo banco de dados e sim pela aplicacao. Isso permite que hajam dados inconsistentes no banco de dados como, por exemplo, um comentario de um blog que nao tem nenhum post associado.Apesar deste cenario ser ficticio e ocorrer apenas quando alguem altera os dados diretamente pelo banco de dados e nao pela opcao de criacao de conteudo, esta possibilidade de inconsistencia pode gerar problemas, principalmente quando se fala em migracao de dados e seguranca.Existem varias caracteristicas e pontos do modelo do Joomla que podem ser analisados. O proprio Torkil Johnsen ja apresentou diversos aspectos do modelo que ele cre que podem ser melhorados no artigo chamado The Joomla database schema smells.Os principais pontos que ele destaca sao a falta de padronizacao e problemas de nomenclatura, tipos de dados, normalizacao e falta de completude do modelo. Concordo com muitos dos pontos levantados pelo Torkil e aqui vou colocar algumas consideracoes minhas e, quando possivel, realizar pequenas comparacoes com o modelo de dados do Wordpress.O modelo do Joomla possui mais de 30 tabelas divididas em grupos como publicacao de conteudo, componentes, menus, templates e outros. Essas divisoes foram destacadas em retangulos com nomes na Figura 1.Ja o Wordpress e mais enxuto e contem 11 tabelas. Existe uma correlacao entre a quantidade de tabelas e colunas de um modelo e a sua complexidade, especialmente em aplicacoes simples que nao estao associadas a toneladas e toneladas de requisitos e casos de uso com diferentes tipos de usuarios.Ou seja, quanto mais tabelas/colunas em um modelo de dados provavelmente ele vai ser mais complexo de ser compreendido, vai dificultar tarefas de importacao/exportacao e possui e tendencia de introduzir complexidade desnecessaria.A principal tabela do modelo do Joomla possui o sufixo _content e e responsavel pelo armazenamento de informacoes sobre o conteudo (como posts em um blog). Esta tabela concentra muita informacao nela mesma e possui quase 30 colunas. Obviamente, nem todas as colunas sao preenchidas quando se cria um novo post e muitas destas colunas possuem valores que claramente poderiam ser mais bem aproveitados se estiverem em outra tabela.Por exemplo, a dupla de colunas publish_up e publish_down, ambas do tipo DATETIME, armazenam a data que o post foi publicado e a data em que ele foi retirado do ar. Porem somente duas datas sao armazenadas e nao ha como armazenar o historico de mais de uma data de publicacao e retirada do post. Esta caracteristica se repete ao longo de diversas outras tabelas do modelo.Outro ponto que me chamou a atencao foi a falta de tipos de dados booleanos, que armazenam valores 0/1 ou VERDADEIRO/FALSE ou TRUE/FALSE. Em muitas tabelas existem colunas que, aparentemente, poderiam se beneficiar do tipo de dados booleano como, por exemplo, a tabela _contact_details, que contem uma coluna chamada published