Há algum tempo atrás escrevi um artigo sobre o modelo de dados do Wordpress aqui no iMasters. Desta vez vou analisar e comentar o modelo de dados do Joomla, outro CMS que está se tornando muito popular aqui no Brasil não apenas para a construção de blogs, mas também para a criação de web sites inteiros e complexos.
Assim como o Wordpress, o Joomla pode ser utilizado basicamente de duas formas:
1. Através da contratação e utilização de um hosting especializado que hospedará o site;
2. Através do download e instalação do Wordpress disponível no site oficial do Joomla. Há também uma forte comunidade de usuários brasileiros representados no site oficial do Joomla no Brasil.
O modelo de dados do Joomla
Olá pessoal. Neste artigo vou apresentar mais uma análise do modelo de dados utilizado em um CMS (Content Management System). Desta vez apresentarei o modelo de dados do Joomla, um dos CMSs mais populares.
Há algum tempo atrás escrevi um artigo sobre o modelo de dados do Wordpress aqui no iMasters. Desta vez vou analisar e comentar o modelo de dados do Joomla, outro CMS que está se tornando muito popular aqui no Brasil não apenas para a construção de blogs, mas também para a criação de web sites inteiros e complexos.
Assim como o Wordpress, o Joomla pode ser utilizado basicamente de duas formas:
1. Através da contratação e utilização de um hosting especializado que hospedará o site;
2. Através do download e instalação do Wordpress disponível no site oficial do Joomla. Há também uma forte comunidade de usuários brasileiros representados no site oficial do Joomla no Brasil.
A utilização do Joomla através da contratação de um hosting vai depender das configurações que o serviço de hospedagem fornece.
É comum encontrar painéis de controle e outras interfaces que facilitam tanto a administração como a criação de conteúdo. Contudo, nestas situações geralmente o ambiente está montado e não é preciso interagir diretamente com o banco de dados.
Já a segunda forma de utilização envolve o download, instalação e configuração do Joomla. Neste contexto é preciso conhecimento técnico da instalação do Joomla e suas dependências, como o servidor de banco de dados MySQL, o PHP e o servidor Web escolhido.
Este artigo se concentra nos detalhes técnicos envolvidos no banco de dados. O público alvo deste artigo são profissionais que precisam lidar com instalação, configuração e manutenção do Joomla e não para quem apenas o usa para gerenciar conteúdo.
É razoável admitir que a maioria dos usuários não precise conhecer o modelo de dados devido à facilidade do uso de painéis administrativo e outras interfaces que permitem a publicação de conteúdo neste CMS. Porém, administradores, DBAs, desenvolvedores de plug-ins e quem resolve problemas de desempenho ou integração com o Joomla devem conhecer bem seu modelo de dados.
Uma vez que já foram explicadas as duas formas de se utilizar o Joomla vamos ao modelo de dados que este CMS utiliza.
A Figura 1 apresenta o modelo de dados (isto é, as tabelas e seus tipos de dados) utilizados pelo Joomla 1.6 e modelados na ferramenta de código aberta DBDesigner disponível em diversas plataformas.
Figura 1. Modelo de dados do Joomla 1.6 no DBDesigner
Já a Figura 2 apresenta o mesmo modelo de dados da Figura 1, porém modelado utilizando a ferramenta livre de modelagem e administração chamada MySQL Workbench.
Figura 2. Modelo de dados do Joomla 1.6 no MySQL Workbench.
Os modelos da Figura 1 e da Figura 2 não foram produzidos por mim. O crédito vai para Torkil Johnse, que disponibilizou estes modelos gratuitamente no seu blog nos formatos do MySQL Workbench(MWB), PNG, PDF e SVG.
Nota: as figuras representam um modelo de dados levemente modificado em relação ao modelo original, como o próprio Torkil comenta em seu blog. As principais diferenças são a mudanças de alguns tipos de dados e a colocação de relacionamentos, uma vez que o MySQL com MyISAM não os suporta. Também destaco que o modelo da Figura 2 não apresenta nenhuma informação sobre os índices das tabelas.
Oficialmente não encontrei nenhuma página que contém informações sobre este modelo inclusive com detalhes das tabelas e suas colunas. Mas encontrei uma página apresenta um fraco dicionário de dados sem muitas informações detalhadas a respeito de certas características do modelo como, por exemplo, justificativas a respeito dos tipos de dados. Acesse a página que contém este dicionário de dados simplificado para a versão 1.5.
Assim como o Wordpress, o Joomla não possui um arquivo contendo todos os comandos SQL necessários para a criação do banco de dados, ou seja, é preciso fazer uma chamada a um arquivo .php após as configurações de acesso a banco de dados no painel administrativo.
Antes de começar a análise do modelo é preciso dizer que oficialmente o Joomla só pode ser instalado no MySQL e/ou a extensão MySQLi. Isso quer dizer que se a empresa já possui outro banco de dados, como o PostgreSQL, SQL Server ou Oracle por exemplo, é preciso configurar um ambiente multi-banco, o que possui implicações para quem administra os servidores.
Existem alguns esforços da comunidade para permitir que o Joomla suporte outros bancos de dados, porém estes esforços ainda não foram integrados oficialmente ao projeto. Para mais informações sobre o suporte a outros bancos de dados no Joomla recomendo os seguintes links:
* http://forum.joomla.org/viewtopic.php?t=142051
* http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/bf9b937ff29f9b52?pli=1
* http://forum.joomla.org/viewtopic.php?t=193981
De forma similar ao que acontece no Wordpress, o modelo de dados do Joomla também não contém chaves estrangeiras. O motivo pela ausência de chaves estrangeiras provavelmente é por que ele foi criado utilizando o engine MyISAM do MySQL ao invés do engine InnoDB. Aqui repito o que já havia falado quando analisei o modelo de dados do Wordpress:
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 chamada published 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 a criação de enquetes (polls) cujos dados são armazenados nas tabelas _polls, _polls_menu e _polls_data.
Outro aspecto que me chamou à atenção no modelo foram as tabelas responsáveis pelo armazenamento de informações de propaganda (_banner, _bannerclient e _bannerfinish) que provavelmente vieram como resquício do modelo do banco de dados do Mambo, projeto na qual o Joomla se originou.
Atualmente o modelo de patrocínio em sites evoluiu muito em relação aos antigos banners e creio que estas tabelas acabaram ficando no esquecimento devido à funcionalidades e requisitos de campanhas com links patrocinados e integração com programas de afiliados.
Apesar de não ser difícil compreender o modelo uma vez que se acostume a ele, em algumas situações fica estranho não contar com a nomenclatura e termos já tradicionais.
Por exemplo, em nenhuma tabela/coluna existe o termo comentário. No modelo de dados esta forma de interação do usuário com o post é chamada de mensagens. Já a tradicional forma de taxonomia apresentada por tags é representada por seções e categoria em um post. Já template é utilizado estritamente para menus e não faz referência direta à forma de customização do layout do site.
Novamente, assim como no Wordpress, o modelo de dados do Joomla não possui nenhuma outra integridade de domínio ou stored procedure que faça restrição ao que é inserido no banco. Apesar disso não ser obrigatório, esta prática abre margem para problemas como SQL Injection onde um usuário malicioso pode tentar invadir o site por meio de caracteres especiais.
Além disso, a falta desta integridade pode permitir dados que invalidem a aplicação como, por exemplo, colocar o valor -2 na coluna count da tabela _categories. Há também algumas colunas de tabelas onde o valor NULL é permitido, tornando necessária uma checagem adicional na aplicação.
Enquanto alguns podem argumentar que isso é responsabilidade da aplicação não é raro encontrar bancos de dados com este tipo de integridade de domínio implementada, fornecendo assim mais uma camada de segurança e consistência de dados.
Em resumo pode-se dizer que o modelo do Joomla é robusto e atende à sua necessidade, porém é um modelo que carrega muito do projeto Mambo. O destaque vai para o foco de armazenar no banco de dados informações tanto de conteúdo como de usuários, configurações, comentários, avaliações, menus, etc.
Com certeza este modelo pode ser melhorado nos aspectos de nomenclatura, padronização, tipagem, normalização e outros. E esta melhoria é responsabilidade da comunidade de desenvolvedores e usuários do Joomla. Infelizmente, melhorias profundas no banco de dados requerem tempo conforme o projeto vai ficando cada vez mais maduro.
Apesar destas ressalvas, o Joomla é um bom CMS que pode ser utilizada para montar muitos projetos e sites interessantes. Obviamente, ele precisa evoluir e continuar a inovar no aspecto de funcionalidades, customização e usabilidade.
Sugiro aos desenvolvedores e à comunidade que procurem também aprimorar o seu modelo de dados, o que pode trazer inúmeros benefícios à ferramenta tornando-a cada vez melhor.
iMaster
Nenhum comentário:
Postar um comentário