Continuando o assunto das regras de negócio dentro do banco de dados, hoje eu gostaria de apresentar uma estrutura arquitetural que se tornou um design pattern muito utilizado dentro das equipes que eu trabalho, no qual eu nomeei de “Store Procedure Facade”. Segue a explicação do contexto e um exemplo prático:

Contexto

Dado uma solução que em uma única requisição HTTP necessita acessar o banco de dados remoto N vezes para pegar informações de tabelas diferentes não relacionadas.

Problema

Dada uma situação de três acessos na requisição, 500 usuários simultâneos fazendo essa operação resultara em 1.500 round trips ao banco de dados, necessitando assim de aumento expressivo da configuração do DataSource, aumento no gasto de memória no parse do framework ORM e a redução exponencial do tempo de resposta da requisição.

Solução

Criar uma store procedure utilizada como se fosse uma Facade para encapsular, agrupar e retornar os N acessos de forma com que com um único round trip ao banco seja possível retornar todas as informações necessárias.

Exemplo

Segue um exemplo em SQL Server 2008:

CREATE PROCEDURE procecure_facade_x

AS

SELECT * INTO #parametro1 FROM tabelaX1

SELECT * INTO #parametro2 FROM tabelaX2

SELECT * INTO #parametro3 FROM tabelaX3

SELECT * FROM #parametro1, #parametro2, #parametro3

GO

Veja que é criada uma Store Procedure Facade que faz acesso em três tabelas diferentes, armazenando cada resultado em tabelas temporárias e depois agrupando e retornando como se fosse a uma mesma consulta.

Resultado

500 usuários simultâneos fazendo essa operação resultara em apenas 500 round trips no banco de dados, um por cada requisição, reduzindo expressivamente a configuração do DataSource, reduzindo os gasto de memória com parse do framework ORM e a aumento expressivo do tempo de resposta da requisição.