Banco de dados mais eficiente com Store Procedures

Minha relação com banco de dados sempre foi feita como administrador de sistemas, precisava conhecer o básico de SQL, fazer um dump, recuperar um dump, ajustes para performance, etc. Sempre tive um DBA do meu lado, o que me deixou bastante preguiçoso no assunto. Todas as tarefas de banco, eu passava para o DBA que em poucos segundos devolvia uma lista de queries para rodar no banco e devolver o resultado que esperava.

Os tempos mudam, empregos mudam e nem sempre tem um DBA à disposição. Tive que mergulhar em banco de dados, aprender tudo aquilo que o DBA fazia por mim. Achei que seria uma tarefa chata, mas pelo contrário, comecei a gostar do assunto e estudar banco de dados a fundo. Valeu o investimento de tempo! Como trabalho com sistemas de busca, o MySQL me atende melhor que o Postgres, por vários motivos. O principal deles é a arquitetura das tabelas MyISAM e o Full Text Search, tarefa que é essencial a quem precisa buscar grandes volumes de textos. Antes que o pessoal do Postgres apareça com pedras nas mãos, sei que o Postgres já oferece o recurso de Full Text Search, mas na época que iniciei meus estudos e necessidades, o MySQL foi o que mais atendeu essa demanda e acabei investindo um conhecimento pesado em cima dele, aprendi várias manhas para ganhar performance e acabou sendo meu banco de dados favorito.

O MySQL até a pouco tempo atrás não oferecia Store Procedures (coisa que o Postgres oferece a muito tempo). Mas as versões mais novas do MySQL oferecem esse recurso e resolvi mergulhar e entender como funciona. É basicamente uma linguagem de programação do banco onde é possível fazer muita coisa e tornar o trabalho mais fácil e a administração mais eficiente. No tempo que comecei trabalhar com MySQL precisei fazer vários scripts em Python para fazer administração do banco, pegar dados e jogar de um lado para outro. Eu estava mantendo esses scripts até a pouco tempo atrás, quando comecei a reescrever suas funcionalidades em Store Procedures. O resultado foi fantástico, scripts Python que levavam vários minutos para ser executado, em Store Procedure preciso de poucos segundos para a mesma tarefa. É um investimento de tempo e estudos que tem retorno.

Para aprender Store Procedures, além do livro da O’Reilly MySQL Store Procedure Programming, tem várias referências na internet, como o próprio site da MySQL e uma série feita pelo Taliba Martins que oferece uma excelente idéia do que é e como fazer as primeiras Store Procedures.

Gostou deste post? Assine gratuitamente o conteúdo e receba as atualizações por e-mail.

E-mail:

Tags:



View Comments ao post “Banco de dados mais eficiente com Store Procedures”

  1. TaQ says:

    Firefox 2.0.0.9 Linux

    O problema é que em muitos casos a portabilidade do seu programa vai para o saco. É só ver sistemas inteiros hoje escritos exclusivamente para o Oracle ou para o SQL Server. :-(

  2. Unknown Linux

    O TaQ tem razão… mas isto está mudando. O PostgreSQL tem o PL/pgSQL que é muito parecido com o PL/SQL do Oracle. O PSM do MySQL é parecido com o do DB2 e já tem uma implementação no PostgreSQL também. Aliás… para coisas simples e dedicadas, o PostgreSQL é uma mãe neste sentido. Use a sua linguagem predileta direto nele: C, Perl, Python, PHP, TCL, Java, etc… O cuidado que se deve tomar é até onde concentrar a inteligência da aplicação no banco. Você pode sentar o servidor se não dimensionar isso direito. E um defeito dos SGDBs é que é muito mais fácil distribuir carga num servidor de aplicação que no banco de dados.

    Ok, eu sei que no seu caso o MySQL foi uma opção melhor e entendo o seu caso. Realmente é um caso muito específico mesmo. Sempre acho que a escolha do seu SGDB tem que passar pelas fazes que você passou. Existem muitas opções, do TXT puro ou XML ao SQLite, BDB e até o Oracle e DB2. Cada projeto é um projeto.

    []s

Deixe um comentário

blog comments powered by Disqus
Get Adobe Flash playerPlugin by wpburn.com wordpress themes