Há uma semana este post tá na fila, esperando que eu tenha uma "opinião formada". Trata da inserção, pela MS, do CLR (Common Language Runtime - base do .NET) na próxima versão do SQL Server, a 2005. Ia passar batido (afinal há um bom tempo a Oracle fez algo semelhante, colocando uma JVM - Java Virtual Machine - em seu banco) não fosse a provocação do John Carrol: "the trend towards moving business logic into the database is enough to make the 3-tier purists wake up screaming in the dead of night."



Não vou fazer escândalo, mas acho que sou sim um 'purista'. E tenho muito trauma com código mastodôntico residindo num lugar que deveria ser apenas um Sistema Gerenciador de Bancos de Dados (SGBD).

Cúmulo do Purista '3 Camadas':

1. Quanto maior a Portabilidade de uma solução, maior sua Qualidade. Vão aparecer os 'práticos' dizendo que se uma aplicação faz tudo que se espera dela, não há o que mexer. Não... até chegar o dia em que a empresa decide mudar de fornecedor e descobre que a migração sairá 150% mais cara que a implementação original. Portanto, cada linha de código no SGBD significa uns $$ a mais no custo de migração de uma aplicação.

2. Performance vale mais que Portabilidade? Pode ser... até o dia que vc buscar Escalabilidade. Esta balança de 'n' pratos é realmente complexa. Mas quando vc arquiteta uma solução olhando 5 anos adiante, algumas respostas ficam mais claras. O equilíbrio é mais lógico.

3. Uma Regra (ou Tarefa ou Processo) de Negócio, enquanto no domínio do Negócio, é uma Unidade muito bem delimitada. Pq sua versão no tal 'domínio da Solução' deveria ser quebrada em partes? O q justifica que parte de uma regra (ou tarefa ou processo) seja um Componente (.NET ou J2EE, não importa) e outra parte uma stored procedure?

Se vc tiver curiosidade em dar uma olhadinha no 'talkback' do post original, lerá umas pérolas do tipo: "já que podemos escrever em C# no banco, podemos dispensar os DBA's"; "a grande razão da inserção do CLR no SQL Server é o enriquecimento do Visual Studio" (?!?!?!); ..."developers could develop their code in such a way, so as to meld their applications to SQL Server 2005, so that it is hard to use another database with their applications. I believe however if developers write their code properly, no greater vendor lock than what exists in products currently on the market, need occur." ...

"If developers write their code properly"...

Fato: o SQL Server tem hoje um valor estratégico para a MS que nunca teve desde sua incorporação. Está no núcleo do adiado WinFS, estará no Exchange e em outros produtos. A MS utilizará para o SQL Server as mesmas táticas de 'lock-in' que marcaram outros itens de seu portfólio. Mas fará o inverso também: o SQL Server está "agregando valor" a outros produtos. O tsunami da comoditização avança rápido em direção dos SGBD's. Não há outra saída senão a busca pela Diferenciação. Se bem sucedida, pode significar uma sobrevida de 2 ou 3 ondas.