SQL Server 2005 New Features: O Database Mail - Parte 2, por Gustavo Maia Aguiar

Gustavo Maia Aguiar é administrador de Empresas pela Universidade de Brasília (UnB) e pós-graduado em bancos de dados pela Universidade Católica de Brasília (UCB), atua na área de tecnologia de informação desde 2001, exercendo funções de desenvolvedor, analista, administrador de banco de dados (DBA) e administrador de dados (AD). É profissional certificado (MOS, MCDBA, MCAD, MCTS (SQL 2005), MCITP (DB Dev), MCITP (DB Admin), MCT e Itil Certified Professional) e suas áreas de interesse incluem .NET, XML, SQL Server, banco de dados em geral e Business Intelligence. É membro ativo dos fóruns MSDN e TechNet além de moderador da comunidade SQL Server Brasil (Orkut).

Conclusão

O envio de e-mails no SQL Server 2005 é bem mais robusto que em versões anteriores. Essa superioridade se dá em diversos aspectos como segurança, flexibilidade, suscetibilidade a erros, etc. Através de comandos em Transact SQL é possível disparar e-mail em uma stored procedure após cadastrar um determinado pedido, criar uma trigger que mande um e-mail se um determinado cliente for excluído, disparar um e-mail com o resultado de um plano de manutenção, etc.

Embora existam todas essas possibilidades é preciso tomar alguns cuidados para que o recurso possa ser utilizado corretamente. Algumas medidas que são bem-vindas:

Use mas não abuse: O fato de ser possível o envio de e-mails em conjunto com stored procedures e triggers não significa que você deva notificar alguém a cada registro inserido, atualizado ou excluído. Lembre-se que o envio de e-mail representa custos tanto para o SQL Server quanto para o servidor de e-mails. Mande apenas por e-mail apenas o que for realmente imprescindível.

Considere formas alternativas de envio de e-mail: Não transforme o seu servidor SQL Server no servidor oficial de envio de e-mails de aplicações. O fato de ser possível enviar e-mail via SQL Server, não quer dizer que todo o envio de e-mail deva ser feito pelo SQL Server. Cada vez que um e-mail é disparado, recursos são alocados. A alocação desses recursos poderia fazer algo mais útil, como por exemplo executar as consultas mais rapidamente, ao invés de disparar e-mails.

Verifique as responsabilidades de cada camada: Algumas vezes, a aplicação poderia realizar o envio de e-mails, ao invés do SQL Server. Se o e-mail precisar estar em um contexto transacional, o envio de e-mail via SQL Server pode ser útil, mas se o e-mail é algo meramente informativo considere colocá-lo no aplicativo

Utilize outras medidas de notificação: Em determinadas ocasiões, se dispara um e-mail para notificar o usuário de um certo evento de interesse. Em alguns casos, o uso do e-mail pode não ser a melhor alternativa. Mostrar as pendências financeiras de um determinado correntista é algo que pode ser apenas mostrado em um sistema de Homebanking. Apesar de ser de interesse, possivelmente a utilização de um e-mail não é a melhor forma para isso.

Cuidados com o SPAM: Lembre-se de que a procedure apenas dispara o e-mail sem qualquer consideração com o destinatário. Se o e-mail é disparado para um destinatário com base em algum campo ou consulta, certifique-se de que não será possível tornar o SQL Server em uma forma de praticar o SPAM.

Portabilidade: Ao utilizar a infra-estrutura de envio de e-mails pelo SQL Server, a portabilidade é reduzida, ou seja, uma troca para outro produto como o MySQL, Oracle, Postgre, etc pode tornar inviável o envio de e-mails gerando retrabalho para que a aplicação garanta essa funcionalidade.

Até a próxima,