Banco De Dados MySQL

O MySQL apresenta a criação de chaves estrangeiras com o engine InnoDB a partir da versão 3.23.43b. O MySQL já está na versão 6, porém há o famoso problema de compatibilidade com as base legada. Provavelmente escolheu-se o MyISAM por facilidade e por motivos de desempenho, o que NÃO quer dizer que um banco de dados com o InnoDB não possa ser ajustado para ter uma desempenho aceitável.

Sem entrar em uma discussão mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor desempenho que o InnoDB, porém este último possui suporte a transações, integridade e outros recursos que o MyISAM não possui.

A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas não é mantido pelo banco de dados e sim pela aplicação. Isso permite que hajam dados inconsistentes no banco de dados como, por exemplo, um comentário de um blog que não tem nenhum post associado.

Apesar deste cenário ser fictício e ocorrer apenas quando alguém altera os dados diretamente pelo banco de dados e não pela opção de criação de conteúdo, esta possibilidade de inconsistência pode gerar problemas, principalmente quando se fala em migração de dados e segurança.

Existem várias características e pontos do modelo do Joomla que podem ser analisados. O próprio Torkil Johnsen já apresentou diversos aspectos do modelo que ele crê que podem ser melhorados no artigo chamado The Joomla database schema smells.

Os principais pontos que ele destaca são a falta de padronização e problemas de nomenclatura, tipos de dados, normalização e falta de completude do modelo. Concordo com muitos dos pontos levantados pelo Torkil e aqui vou colocar algumas considerações minhas e, quando possível, realizar pequenas comparações com o modelo de dados do WordPress.

O modelo do Joomla possui mais de 30 tabelas divididas em grupos como publicação de conteúdo, componentes, menus, templates e outros. Essas divisões foram destacadas em retângulos com nomes na Figura 1.

Já o WordPress é mais enxuto e contém 11 tabelas. Existe uma correlação entre a quantidade de tabelas e colunas de um modelo e a sua complexidade, especialmente em aplicações simples que não estão associadas a toneladas e toneladas de requisitos e casos de uso com diferentes tipos de usuários.

Ou seja, quanto mais tabelas/colunas em um modelo de dados provavelmente ele vai ser mais complexo de ser compreendido, vai dificultar tarefas de importação/exportação e possui e tendência de introduzir complexidade desnecessária.

A principal tabela do modelo do Joomla possui o sufixo _content e é responsável pelo armazenamento de informações sobre o conteúdo (como posts em um blog). Esta tabela concentra muita informação nela mesma e possui quase 30 colunas. Obviamente, nem todas as colunas são 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. Porém somente duas datas são armazenadas e não há como armazenar o histórico de mais de uma data de publicação e retirada do post. Esta característica se repete ao longo de diversas outras tabelas do modelo.

Outro ponto que me chamou a atenção 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 contém uma coluna chamadapublished do tipo de dados TINYINT(1).

Além disso, destaca-se também o uso em excesso de colunas com o tipo de dados TEXT, algo que permite o armazenamento de dados limitado apenas pelos recursos do servidor e não por um número fixo de caracteres.

O uso em excesso de colunas do tipo TEXT pode eventualmente se tornar um problema devido à grande quantidade de caracteres armazenados e à necessidade de backups específicos por tabelas. Sem contar que a indexação e pesquisa para este tipo de dados devem ser especiais, algo que não é tratado no Joomla diretamente.

Do ponto de vista de modelagem, em algumas situações o modelo atende a certos requisitos relativamente bem, como é o caso do gerenciamento de usuários, grupos e permissões.

Por outro lado, algumas tabelas deveriam ser implementadas como plug-ins ou extensões e não diretamente no modelo padrão, como é o caso do gerenciamento de avaliação (rating) de um post cujos dados são armazenados na entidade_content_rating.

Outro exemplo de tabelas que seriam mais bem aproveitadas em plug-ins ou extensões está relacionado com