Não se esqueça que pode contar com Stored Procedures

Um caso real: em 98 estava numa sessão de JAD (Joint Application Development) ajudando a definir a tecnologia de um projeto que seria orientado a objetos quando chegamos à questão relatórios. Perguntei ao grupo se iriam usar um gerador de relatórios e ... silêncio. Todos olharam para mim e para o consultor que seguiria com eles na modelagem e construção do sistema. Num salto, o consultor afirmou: "faremos nossos relatórios usando OO".

Perguntei ao grupo se conheciam o impacto desta decisão... silêncio.

Eu tinha duas preocupações: produtividade e desempenho.

Comecei então com meu exemplo costumeiro. Um relatório para listar Bancos, Agências e Contas.

No modelo OO, construímos um loop sobre a lista de bancos, dentro dela outro loop sobre as agências para, num loop final, alcançar as contas. Se não houver um bom mapeamento entre o relacional e objetos, isto costuma provocar um número enorme de selects (1 para os n bancos, n para as m agências e m para as contas = 1*n*m).

Em contraste, usando o poder do join, no relacional, seria possível trazer os dados e uma única querie.

Depois das explicações, voltei ao grupo. Vocês não preferem um gerador de relatórios?

Olhos no consultor. Logo ele nos dá seu ponto de vista: “sou matemático e entendo que temos que uniformizar o modelo de programação para um único modelo: o OO”.

Brincando, respondi: “além de engenheiro sou carioca” (risos – eu estava em São Paulo. Somos famosos aqui pelo jeitinho ou, pior, a malandragem). “Se tiver que misturar meu paradigma para tornar a engenharia e o custo viáveis, não duvido muito.”

Fomos à votação e o modelo OO ganhou. Não usaram um gerador de relatórios.

Ouvi anos depois que o projeto não foi bem. Não sei se por causa dos relatórios, mas desconfio que pela mudança cultural e excesso de idealismo.

Conto isto tudo para poder dar um conselho: é muito bom poder contar com queries Linq que trazem em um único select Banco, Agência e Conta. Mas não se esqueçam que, quando estiverem usando um ORM, o algoritmo tenderá a um ninho de loops sobre a coleção de objetos em memória – o que também é ruim. Neste caso, operações relacionais mais complexas podem ser necessárias. Lembre-se: não tenha medo de usar stored procedures, se necessário.