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.
Tags: MySQL
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.
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