Mitos sobre Stored Procedures

Fala Giovanni!

Se utilizarmos, por exemplo, o SSIS, nem a questão de duplicidade de regras de negócio chega a ser um problema, já que podemos executar códido de libraries (DLL's) .NET. Aliás, isso é possível diretamente no SQL Server.

O fato, é que processos ETL possuem particularidades, incluindo negócio, que dizem respeito a infra, estratégias de distribuição das fontes de dados, etc. E isso vai mais além quando envolvemos um OLAP. Assim sendo, não vejo muito como um ORM pode ser inserido em alguma ponta.

Outro ponto que gostaria de comentar é sobre sua última frase onde você incita o uso de bancos NOSQL. Acho muito importante ressaltar os cenários que uma forma de armazenamento dessas é indicada. Li um artigo muito interessante uns meses atrás que falava da BigTable do Google, era quase um artigo acadêmico, escrito pelos criados do BigTable. Lendo o artigo, fica bastante claro que tipo de necessidade cai bem pro NOSQL.

Enfim, eram só essas considerações. Bacana ver posts técnicos no Unplugged, Giovanni! Estava com saudades!

Abraços,

Leandro Daniel

Fala Giovanni,
eu concordo com isso tudo que falou e ainda acho um dos principais problemas de Procs é que elas violam o conceito do DRY.
Porque se você modifica sua tabela, além de modificar no código ainda tem que modificar nas procs.
Abraços
Thiago Temple

Outra vantagem das procedures, é que vc pode fazer modificações nas instruções sem ter que compilar toda a aplicação novamente.

"Outra vantagem das procedures,...."

Como assim "outra"? Você leu bem o post? Ele não fala de vantagens em usar SP e sim o contrário!!!

Olá a todos.

Muito interessante o Post e também muito esclarecedor.

No entanto, de fato acredito que existam alguns cenários em que as Procs são interessantes. Por exemplo, quando eu trabalhava com CSLA em uma outra empresa, que também possuiam bibliotecas de acesso a BD, em determinadas situações ficava interessante utilizar as Procs, justamente pela não necessidade de recompilar o código, etc, em caso de modificações.

Mas acredito que o fato é justamente esse: utilizar as Procs quando as mesmas são realmente interessantes para a produtividade, segurança, etc, e não apenas baseando-se em mitos, como disse o Giovanni.

Até mais.

Não vejo nenhuma vantagem em usar PROC, além disso devemos lembrar que PROCS fazem com que as nossas aplicações tenham um alto nível de acoplamento e isso é péssimo do ponto de vista OO.
O que tenho visto por ai são sistemas feitos em 3 camadas com praticamente toda a regra de negócio no banco de dados dentro de SPs e muita regra de negócio também sendo feita na tela(JS,Code Behind), francamente isso é horrível e o pior a camada de "business" geralmente não tem nada de regra de negócio a unica coisa que ela faz é uma ponte entre a camada de dados e a camada de User Interface.
Ainda ontem eu estava tendo essa mesma discussão com o pessoal aqui da empresa. E minha opinião mesmo é de que não sou a favor nunca de usar SPs a não ser é claro que eu esteja em um projeto de banco de dados.

Resp 1: A Afirmação acima está correta, os planos de execução são gerados para todo tipo de consultas realizadas no banco.

Resp 2: Isso depende muito do tipo de sistema e do tipo da regra, pois desenvolver um sistema simples como um controle de estoque, o qual não é integrado a mais nada, é muito mais coerente manter a regra dentro do próprio sistema, via OO, como por exemplo, uma rotina para recalcular o estoque. Mas se este sistema de controle de estoque for parte de uma regra maior em uma empresa, onde este possui vínculos ao  controle de patrimônio e ao sistema financeiro, já é muito pais interessante manter esta regra no banco de dados, pois assim o sistema financeiro, pode buscar a posição real do estoque atravez da mesma procedure que o controle de estoque utiliza. E isso é quase que obrigatório se os programas forem escritos em tecnologias diferentes.

Resp 3: Ops...  Vamos ver então o exemplo do calculo da folha de pagamento, de 20000 funcionários, sendo que para isso, o sistema deve fazer consulta a várias tabelas ao mesmo tempo, e se esta regra estiver no programa, vai gerar um grande volume de dados indo e vindo pela rede, prejudicando o desempenho do sistema ou da própria rede (Conforme infra-estrutura a ser usada), prejudicando os demais sistemas. Já com está operação dentro do banco, a aplicação apenas envia o comando para executar o calculo, onde o DB vai executar  a operação, não gerando trafego de rede e nem o risco de no meio do calculo acontecer alguma coisa com a rede. Lembrando que nas duas maneiras, o servidor de DB vai ser utilizado, mas com a regra no banco, o acesso é bem mais rápido, pois não existe espera de resposta da aplicação externa.

Resp 4: VERDADE... para demostra isso, vamos a seguinte situação, Cadastro de funcionários, onde o valor do salário não pode ser alterado por todos, mas outros campos sim, então podemos tirar o acesso de alteração da tabela, e deixar apenas um usuário interno do banco com este direito. Então podemos criar uma procedure para executar a alteração no banco, e dar o direitos aos usuários. Mas internamente a procedure vai verificar qual grupo de usuário você faz parte, e então internamente troca o escopo de execução para o usuario interno informando a senha com direito de updade, e executa o update, alterando ou não o salário, conforme regra. Desta maneira a alteração da tabela só pode ser feita pela procedure, garantindo toda a segurança da mesmo.

Resp 5: Concordo, referente a uma operação de consultas, mas quando tomos uma consulta que retorna um conjunto pequeno de dados, que são obtidas através do resultado de vários outras operações, ai sim a procedure é bem mais interessante, pois o consumo de bando é bem menor, pois a ida ao servidor é apenas da chamada a procedure, e não de todas as sentença SQL para buscar o resultado.

Resp Final: Produtividade X Desempenho - Aqui entra outro fator, pois vai depender muito da necessidade. Se for Produtividade, legal usar ORM, mas se for Desempenho, melhor programar as coisa na mão, dosando banco X OO, conforme necessidade, já que é importante ressaltar que muitos dos recursos de Mapeamento objecto-relacional (ORM) , fazem muito uso de código de Reflexão,  tendo assim uma perda razoável de desempenho e um consumo elevado de memória, o qual para uma simples operação não é relevante, mas quando nos referimos a processamento, faz bastante diferença, como exemplo: Calcular folha de pagamento,   IPTU, ISSQN, etc...

Giggio,
Analisando o post, e os comentarios contra as procs, me senti na "obrigação" de escrever. rss

Bom, pra começar, o SQL Server executa TUDO JUNTO e não linha a linha. Se você precisa integrar algumas atividades ad-hoc vc terá que chamar cada uma separadamente. Isso aumenta a quantidade de trabalho que será realizada no software, rede e no banco.

A idéia de usar procs e não ad-hoc nos garante a possibilidade de uma procedure chamar outra, internamente, e o banco de dados é preparado para realizar isso de forma performática.

Outro ponto que DEVE ser levado em consideração é a questão de tunning. Não que em ad-hoc não seja possivel ter uma boa query, mas dentro do SQL Server a execução É INTERNA E O DBMS É PREPARADO PARA ISSO.

É isso ai galerinha, não sejam radicais e parem de usar procs da noite para o dia. Veja o que sua NECESSIDADE pede.

Abraços,
Diego Nogare

Boa Noite a todos,

Vou compartilhar a experiencia que tenho no meu dia a dia de trabalho.
Sou DBA de uma empresa que desenvolve seu próprio sistema com uma equipe de uns 20 desenvolvedores.
Como DBA monitoro o banco a procura das querys mais lentas e que consomem mais recursos. Ja perdi as contas do número de ad-hoc querys que identifiquei em meus logs e depois de otimizar as mesmas, como elas estavam no código não era possível alterá-la imediatamente, o que eu faço quando encontro uma procedure com um desempenho ruim. Tenho mandar um e-mail para o desenvolvimento para que encontrem a tela que contém a query e no fim do dia ou de manhã cedo, eles subam o sistema com uma SP no lugar da query.

Outro exemplo,
Um exemplo de ad-hoc querys que chegam no meu Banco de Dados. Elas chegam exatamente assim no meu trace.
Select * from cliente where Nr_DOcumento = '11111111111'
Select * from cliente where Nr_DOcumento = '22222222222'

Essas querys geram 2 planos de execução diferentes que não são reaproveitados.

create procedure dbo.stpGet_Cliente @Nr_Documento char(11)
AS
Select * from cliente where Nr_DOcumento = @Nr_Documento

exec dbo.stpGet_Cliente '11111111111'
exec dbo.stpGet_Cliente '22222222222'

Essas duas chamadas utilizam o mesmo plano de execução, diminuindo assim o espaço utilizado no plan_cache.
Isso acontece tanto no 2005 quanto no SQL 2008 R2. O cache das querys pode ser acompanhado com a query abaixo:
SELECT  text,plan_handle, cp.size_in_bytes,usecounts
FROM sys.dm_Exec_cached_plans AS cp
      CROSS APPLY sys.dm_exec_sql_text(plan_handle)


No meu ambiente, prefiro colocar tudo em procedure. Como o Diego disse, não é para ser radical. Depende do ambiente e da necessidade.

Olá pessoal, penso que não existe a forma ideal de desenvolvimento que englobe todos os projetos de softwares. O que deve ser avaliado é dentre as possibilidades a que melhor atenda os recursos e os objetivos disponíveis para o projeto. Por este motivo não existe melhor linguagem, melhor SO, melhor SGDB ou melhor metologia. Esta polêmica é boa e sempre gera inúmeros embates entre os defensores de uma ou outra metodologia. Será que é um erro em um projeto usar somente ORM ou num outro usar somente sp ou em um outro usar ORM  e sp em conjunto?

Olá,

A respeito de procedimentos que nos retornam ou manipulam uma quantidade de registros da monta de milhões? É possível executá-los com ORM? E a questão da performance, direto no banco alguns dos quais trabalho duram 30, 40 minutos até mais depende de quantos estão pendurados, como fica com ORM?

Abs.
J.ALEXANDRE

+1

"É isso. Joguem as procs no lixo, programem com ORMs (ou bancos NOSQL), e sejam produtivos."

Olá Giovanni,

Como o próprio título do post deixa claro, a sua ideia foi apresentar algumas informações sobre vantagens das stored procedures que você julga como “mitos”, independente de contexto. Mas, será que você realmente conseguiu fornecer argumentos suficientes para deduzir que estas afirmações são “mitos”? Eu não vou comentar cada um das cinco afirmações apresentadas para tentar não estender demais o comentário. Observe que, na sua análise, você entra em contradição algumas vezes.

Por exemplo, veja a sua afirmação 2: “Stored Procedures estimulam reusabilidade.”. Agora veja a sua argumentação para justificar que esta afirmação é um mito: “Reusabilidade pode ser atingida de diversas formas. Um modelo procedural, como o da programação de um banco de dados relacional, possibilita reusabilidade dentro deste paradigma. Eu prefiro estimular reusabilidade com OO, mas isso não quer dizer que não podemos reutilizar tanto em um quanto no outro.”. Ou seja, a sua própria justificativa é uma contradição de que a afirmação 2 é um mito. Você acha que o fato da sua preferência em usar POO para reusabilidade é uma justificativa suficiente para concluir que a afirmação 2 é um mito?

Outro exemplo de contradição pode ser encontrado na afirmação 3: “Stored Procedures ajudam a encapsular regras de negócio.”. Agora veja a sua argumentação para justificar que esta afirmação é um mito: “Eu posso encapsular, com mais produtividade na programação, em um modelo OO.”. Mais uma vez, a sua própria justificativa é uma contradição de que a afirmação 3 é um mito. O fato de você achar POO mais produtiva para encapsular regras de negócios que stored procedures torna a afirmação 3 um mito? Outra coisa, você acha que a sua conclusão é válida para qualquer contexto?

Eu quero deixar claro que sou adepto das técnicas de POO, que considero como um dos modelos de programação atuais mais poderosos para encapsulamento de regras de negócios de uma aplicação. Além disto, eu sou a favor do uso de frameworks de mapeamento objeto-relacional (ORM), como o NHibernate e o Entity Framework, para gerenciar a persistência dos dados no desenvolvimento de aplicações. Porém, eu não considero os bancos de dados como meros repositórios de dados neste processo. Dependendo do contexto, eu sou a favor do uso de todos os recursos disponíveis no banco de dados para permitir o um melhor desempenho da aplicação. Muitas vezes, o desempenho é fundamental para se atender algum requisito de um sistema. E existem contextos, que não são tão raros, em que stored procedures se encaixam como uma luva. Veja a descrição de um exemplo real abaixo, onde eu usei stored procedures na prática.

Imagine um sistema com um modelo de banco de dados composto por diversas tabelas. Duas tabelas relacionadas deste banco de dados estão sendo populadas dinamicamente com dezenas de milhões de registros cada uma. A aplicação precisa gerar relatórios, em tempo real, para encontrar discrepâncias entre estas dezenas de milhões de registros para serem corrigidas pelos usuários. Porém, é sabido que os dados do resultado da análise das discrepâncias ficam na ordem de centenas de registros. Neste contexto, stored procedures podem ser usadas para incluir as regras de negócios necessárias para se encontrar as discrepâncias e retornar para aplicação somente as centenas de discrepâncias para correção dos usuários. Esta é uma situação real, onde eu usei stored procedures para solucionar o problema. Os relatórios eram gerados com frequência e em tempo real, sem sobrecarregar o servidor de banco de dados e nem a rede pelo tráfego de milhões de registros.

Giovanni, que solução você daria para geração dos relatórios, com frequência e em tempo real, no contexto apresentado acima somente com uso de ORM e com as regras de negócios para encontrar as discrepâncias em classes definidas usando-se boas práticas de POO? Você usaria o framework de ORM para trazer as dezenas de milhões de registros do servidor de banco de dados para o servidor com as regras de negócios e os carregaria em objetos na memória para serem processados pelos objetos contendo as regras de negócios?

Abraços,

Rogério Moraes de Carvalho

Olá Giovani!
Obrigado por sua atenção.
Há cenários em que a manipulação de registros da monta citada é inevitável, por exemplo, uma consulta a base de um CALL CENTER com 3 mil PAS usando um range de datas de 15 dias, não há como evitar esta manipulação. Como seria a performance usando ORM em vez de usar SP?
Então não é o injustificável, é que software precisa ser moldado ao negócio, e não o contrário como  propõe.
Mais uma vez obrigado!
Abs.
J. ALEXANDRE

Olá Giovanni,

Como você mesmo disse: "Entendo que minhas afirmações são sim independentes de contexto, e coloquei uma exceção para o contexto no final: ETL.". Em TI, assim como em outras áreas do conhecimento, em geral as proposições somente são válidas quando analisadas num determinado contexto.

O exemplo que eu citei não é um caso de ETL.

Vou explicar novamente o contexto do exemplo, de um modo um pouco diferente, para deixar claro que não se trata de um caso de ETL. Num sistema em produção são gerados dezenas de milhões de registros em um banco de dados OLTP (OnLine Transaction Processing - http://en.wikipedia.org/wiki/OLTP). Durante o processo de cadastro dos registros, é usado um framework ORM para persistência dos dados. Eu preciso gerar um relatório gerencial de discrepância dos dados em tempo real. Atualmente, este relatório está sendo gerado com uma stored procedure, que possui as regras de negócios para encontrar as discrepâncias entre as dezenas de milhões de registros, e que, normalmente, resulta em algumas centenas de registros com as discrepâncias. Estas centenas de registros são transferidas para aplicação cliente, em tempo real, com uso do framework de ORM.

Veja a definição dada na Wikpedia, que você mesmo citou e colocou um link no seu post:
"Extract, transform, and load (ETL) is a process in database usage and especially in data warehousing that involves:
- Extracting data from outside sources
- Transforming it to fit operational needs (which can include quality levels)
- Loading it into the end target (database or data warehouse)"

Em ETL, normalmente ocorre a extração de um grande volume de dados, que são transformados e carregados em um banco de dados ou em um data warehouse. No exemplo citado, um grande volume de dados é analisado (dezenas de milhões de registros) para se encontrar discrepâncias e o resultando é passado para a aplicação cliente (centenas de registros). Ou seja, eu não farei carga de dezenas de milhões de dados transformados num banco de dados ou num data warehouse.

Deste modo, segue a mesma pergunta que eu fiz anteriormente:
“Giovanni, que solução você daria para geração dos relatórios, com frequência e em tempo real, no contexto apresentado acima, somente com uso de ORM e com as regras de negócios para encontrar as discrepâncias em classes definidas usando-se boas práticas de POO?”

Olá Giovanni,

Eu, particularmente, não considero que este processo tenha uma “imensa” semelhança com ETL. Seguem os comentários dos 3 itens que você citou no seu comentário, cada um deles relacionado com uma das etapas de um processo de ETL.

1) “Não há Extract, os dados já estão no banco.”.

Faço minhas as suas palavras. Somente de não ter esta fase, já deixou de ter uma “imensa” semelhança com ETL.

2) “Há a transformação”.

Observe que não há uma transformação no sentido proposto no conceito de ETL. Pois, há uma análise dos dados armazenados no banco de dados, de acordo com uma regra de negócios, que, normalmente, gera outro conjunto de dados. Eu não estou fazendo uma transformação dos dados para dar carga em um banco de dados ou em um data warehouse. Sendo que se estas discrepâncias não existirem, nem mesmo existirá um conjunto de registros como resultado.

3) “Há a carga para consulta resultado da transformação.”

Também não há carga do resultado da transformação no sentido proposto no conceito de ETL. Eu não estou fazendo carga dos dados resultantes da “transformação” num banco de dados ou num data warehouse. Simplesmente, eu estou transferindo os dados, que são resultados de uma análise num grande volume de dados, diretamente para a aplicação cliente usando um framework de ORM.

No restante, eu achei o seu comentário muito pertinente, incluindo as sugestões. Veja o início do seu comentário:
“Se eu conhecesse melhor o cenário, poderia propor outras alternativas, que podem ou não fazer sentido, ...”.
Veja que você mesmo precisaria conhecer melhor o contexto do problema para poder propor soluções que não sejam pelo uso de stored procedures. O que vai de encontro direto ao que eu escrevi no meu comentário anterior:
“Em TI, assim como em outras áreas do conhecimento, em geral as proposições somente são válidas quando analisadas num determinado contexto.”.
Porém, você é incisivo ao dizer que "suas afirmações são sim independentes de contexto" ao condenar stored procedures em qualquer contexto que não seja ETL.

Agora, nós estamos chegando num ponto bem interessante desta nossa análise. Até onde as sugestões que você está propondo, que são soluções possíveis para o problema que eu descrevi, correspondem a melhores práticas do que o uso de stored procedures? Até onde você está sugerindo soluções que estão de acordo com as práticas que você defende no seu post original?

Seguem comentários das duas sugestões que você forneceu.

SUGESTÃO 1) "Desnormalizar as tabelas principais, de modo a criar um modelo único de reporting, mantendo as outras tabelas para manipulação apenas. Isso permitiria obter as discrepâncias com um único Select."

Inclusive, esta sua sugestão é utilizada internamente na solução com uma stored procedure. Há uma tabela principal desnormalizada que garante o desempenho da consulta que gera as discrepâncias. Porém, na própria consulta SELECT está sendo usada a regra de negócios para filtrar as discrepâncias. Observe, inclusive, que eu poderia estar chamando funções definidas pelo usuário no banco de dados nesta consulta SELECT. Ou você acha que o simples fato de usar um único SELECT quer dizer que não estou usando regras de negócios no banco de dados?

Porém, eu entendo perfeitamente porque você está querendo transformar numa consulta simples. Deste modo, você poderá executar esta consulta diretamente a partir de um framework de ORM, sem a necessidade de usar stored procedures. Ou seja, simplesmente para tentar provar a sua teoria que somente há "um caso onde vejo (no caso, você) uso de procs como útil: ETL.". Observe que nesta solução proposta por você, não haverá o uso de stored procedures, mas as regras de negócios estarão embutidas no seu SELECT único.

Mas, no seu post original você escreveu:
"3.Stored Procedures ajudam a encapsular regras de negócio.
Mito. Eu posso encapsular, com mais produtividade na programação, em um modelo OO.".

Na solução proposta por você (SELECT único), onde está o uso do modelo OO?

Como eu vou usar os recursos de POO, como polimorfismo, por exemplo, para modificar as regras de negócios para filtragem das discrepâncias?

SUGESTÃO 2) "Outra: trabalhar online e sempre que um dado entrar já buscar os outros que podem estar discrepantes, evitando o processo em batch."

No contexto descrito, eu não considero esta solução uma alternativa tão boa quanto a anterior. Isto porque os dados são modificados constantemente. Deste modo, uma discrepância num determinando momento, pode ter sido eliminada num momento logo posterior. Você ainda precisaria persistir estas discrepâncias encontradas e depois gerenciar suas exclusões quando elas fossem resolvidas. O que seria um processo oneroso e sujeito a falhas, uma vez que as discrepâncias persistidas constantemente ficariam desatualizadas em relação aos dados armazenados no banco de dados.

Fala Giovanni.

Obrigado pelo toque.

Entendo perfeitamente que há outros modos de distribuição e manutenção da aplicação... Mas na verdade o que eu quis dizer não foi exatamente isso...

Está um pouco mais para o que o Diego Nogare disse: eu acho que é preciso analisar cada caso e chegar a uma conclusão... E eu já enfrentei casos em que era interessante utilizar as Procs (não só por questão de distribuição, mas também de legibilidade de código, facilidade de manutenção, etc) e também houveram momentos em que elas eram, no mínimo, desnecessárias.

Até mais.

É muito mais facil comprar um computador a mais para o processamento do que pagar 20 funcionarios para corrigir procedures, ou dar manutencao em código que utiliza procedures.
Pessoas acham que utilizando ORM, você pode perder performance, o que eu acho eh que essas pessoas nao conseguem elaborar uma boa arquitetura em seu software, e quando o sistema esta no gargalo apelam para stored procedures. Eu sou extremamente radical, a programação é muito mais extensivel e flexivel que o banco de dados, portanto é muito mais facil vc elaborar um esquema de peformance na aplicação do que no banco de dados. No banco de dados, a unica coisa que vc otimiza é as procedures, agora na aplicação vc tem inumeras arquiteturas q lhe possibilitam isso.

Olá Danimar,

Se você leu os comentários anteriores deve ter percebido que a discussão está no fato de que o autor do post, o Giovanni Bassi, afirma: “Entendo que minhas afirmações são sim independentes de contexto, e coloquei uma exceção para o contexto no final: ETL.”. Ou seja, ele somente acha justificável o uso de stored procedures para casos de ETL. Para todos os outros casos, independente de contexto, ele condena o uso de stored procedures.

Porém, afirmações soltas e sem embasamento técnico não tem valor algum. Sendo assim, eu apresentei um exemplo de uma situação concreta onde eu usei stored procedures na prática para resolver um problema de desempenho num sistema, e não se trata de um caso de ETL.

Se você quer colaborar tecnicamente com a discussão, então pode sugerir uma solução para o problema proposto usando somente framework de ORM e POO para garantir as regras de negócios usadas para encontrar as discrepâncias.

O Giovanni Bassi já deu duas soluções possíveis para o problema. Por enquanto, eu estou aguardando as respostas dele para todos os questionamentos no meu comentário anterior.

Atualmente, eu tenho usado o Entity Framework 4 ou o NHibernate for .NET 2.0.1 para manipular a persistência de objetos .NET de e para bancos de dados relacionais. Além disto, eu uso o padrão de repositório para ajudar a encapsular a consulta dos dados e a lógica de persistência. Deste modo, eu posso abstrair do restante da aplicação os detalhes de implementação da persistência de dados. Em geral, eu não tenho usado stored procedures nos sistemas que desenvolvo. Mas, eu tenho o bom senso de identificar situações em que stored procedures fornecem uma excelente opção para ganho de desempenho em relação ao uso puro de ORM, sem stored procedures. Uma situação clara é quando preciso analisar milhões de registros, em tempo real e num banco de dados OLTP, para gerar um relatório de consolidação dos dados. É inconcebível na questão de desempenho, neste contexto, trazer os milhões de registros com um ORM para a memória para fazer a análise usando POO. Para piorar as coisas, estes relatórios, em tempo real, podem estar sendo gerados por vários usuários simultaneamente.

Para todos aqueles que concordam integralmente com tudo que foi escrito pelo Giovanni Bassi neste post, inclusive nos comentários dele, eu fico aguardando propostas técnicas de soluções para o problema proposto.

Ola Rogerio.
Com certeza não tenho como lhe dar uma solução, pois não conheço seu diagrama de classes, a sua arquitetura do projeto, é muita vaga a ideia de criar relatorios em tempo real, com uma grande massa de dados. Voce poderia fazer sumarização, vc falou q fez, mas ate que ponto vc fez, daria pra melhorar isso?
Mas com certeza existe uma forma de se fazer isso, atraves da programação, como falei a sua aplicação pode ser muito mais flexivel, do que o banco de dados.
Voce esta sempre pensando em juntar os dados e processar, com certeza com ORM esta n'ao eh a abordagem certa para este caso.

Olá Danimar,

No seu primeiro comentário, você afirmou: "Pessoas acham que utilizando ORM, você pode perder performance, o que eu acho eh que essas pessoas nao conseguem elaborar uma boa arquitetura em seu software, e quando o sistema esta no gargalo apelam para stored procedures.".
Então, eu forneci um exemplo concreto de um contexto onde usei stored procedures para resolver um problema de desempenho, ao invés de usar ORM.

No seu outro comentário, você afirmou: "Com certeza não tenho como lhe dar uma solução, pois não conheço seu diagrama de classes, a sua arquitetura do projeto, é muita vaga a ideia de criar relatorios em tempo real, com uma grande massa de dados. Voce poderia fazer sumarização, vc falou q fez, mas ate que ponto vc fez, daria pra melhorar isso?"
A ideia não é você repassar a pergunta para mim. Eu dei uma solução possível, com uso de stored procedures. Não sou eu que estou concordando com os argumentos do autor do artigo, mas sim você. Você não precisa conhecer o diagrama de casses e a arquitetura do projeto para dar uma solução macro para o problema usando ORM.
Basta você dizer como eu posso fazer uma análise de regras de negócios em milhões de registros para gerar como resultado apenas algumas centenas de registros ou menos, sem a necessidade de jogar regras de negócios no banco de dados.

Depois, você ainda afirma: “Mas com certeza existe uma forma de se fazer isso, atraves da programação, como falei a sua aplicação pode ser muito mais flexivel, do que o banco de dados.”.
Então, você concorda com o autor do artigo porque “com certeza existe uma forma de se fazer isso”, mesmo que você não saiba qual. Você acha que este seu argumento é suficiente para sustentar as ideias colocadas neste post?

Finalmente, você termina o seu comentário: “Voce esta sempre pensando em juntar os dados e processar, com certeza com ORM esta nao eh a abordagem certa para este caso.”.
Agora, você chegou exatamente no ponto que eu estava querendo. Não é uma “abordagem certa” usar ORM para trazer as dezenas de milhões de registros para a memória para aplicar uma regra de negócios e filtrar apenas algumas centenas ou menos de registros. Então, sem jogar regras de negócios no banco de dados (seja com stored procedures ou com um SELECT único), como eu poderia resolver este problema?

A discussão é ótima, acadêmica e ainda enriquece mais os defensores do código ideal tanto quanto os espectadores. Porém é uma pena descobrir que tudo isso vai para o "ralo" quando 80% dos gestores de TI acham isto besteira e querem apenas entregar para o cliente final funcionando a todo custo.

Bom Dia Senhores,

Acho a discussão extremamente rica e embora muitos sejam 100% adeptos de stored procedures eu não acho que elas sejam a melhor alternativa em muitos dos casos em que são aplicados. Ao meu ver é muito lamentável ver stored procedures com tarefas que ali não deveriam estar a exemplo de um envio de email, gravação de arquivos, criação de pastas, etc. Em contrapartida, há várias questões que são endereçadas muito bem com uma SP.

Eu discordo de algumas questões colocadas como "mitos" pelas mesmas razões das várias expostas aqui, mas não vou citar as mesmas críticas e nem os mesmos argumentos. Tenho apenas uma crítica em especial sobre a sugestão do ETL.

Ao meu ver, uma das piores práticas em processos de ETL é utilizar stored procedures especialmente para grandes cargas. Já vi vários processos de ETL que resultaram em verdadeiros fracassos por conta do uso de stored procedures. Cito algumas razões pelas quais jamais utilizaria stored procedures para processos de ETL "sérios".

- Stored Procedures não são otimizadas para cargas em lote e vão logar tudo no log de transações atrasando a carga
- Stored Procedures são transacionais e um erro pode ocasionar um rollback de um volume de dados gigantesco além de vários bloqueios durante a carga
- Stored Procedures não podem reiniciar de onde pararam e o processo de ETL seria refeito, mesmo que 90% dele já estivesse concluído
- Stored Procedures não podem executar em um servidor isolado e fatalmente irão onerar o servidor de banco de dados
- Stored Procedures não podem executar seus passos internos em paralelo e terão que rodar cada instrução sequencialmente
- Stored Procedures não tem funcionalidades prontas, e será necessário codificar na mão diversar funcionalidades (além do processo) como LookUp, Lógica Fuzzy, Upsert, etc
- Stored Procedures não são apropriadas para trabalhar com conectores heterogêneos
- Stored Procedures não detectam conflitos de metadados previamente podendo repassar dados incorretos se os metadados forem alterados

Acho sim que existem vários prós e contras o uso de procedures, mas ETL não é algo que eu consideraria a favor do lado das Stored Procedures. Não creio também que alternativas como Java, .NET ou ainda ORM consigam dar a performance, o controle e a escalabilidade esperados em um processo de ETL.

[ ]s,

Gustavo Maia Aguiar
Por que utilizar uma ferramenta de ETL ?
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1026.entry

Coloquei algumas observações que podem úteis em meu blog: luticm.blogspot.com/.../...red-procedures-uma.html - Fire at will!

[]s
Luti

@Giovanni,
aqui vao meus 5 centavos...

Concordo plenamente que existem diversas tecnicas inovadoras com o intuito de agilizar o desenvolvimento de aplicacoes.

Todo programador deveria se atualizar e buscar conhecer e utilizar estas novas tecnicas, como voce fez.

No entanto, o que vemos na pratica sao ambientes engessados, que trabalham ha algum tempo com uma determinada politica/cultura empresarial, onde varios "mitos" sao tomados como verdade e utilizados diariamente.

Frequentemente, sou convocado a analisar/criticar sistemas legados, e identificar problemas de estrutura e performance, e uma de minhas solucoes inclusive, eh a utilizacao de Stored Procedures para resolver o problema.

Nao posso chegar numa hora ruim, quando o circo esta pegando fogo, e chutar a canela dos programadores, dizendo a eles que eles deveriam ter estudado mais e utilizado tecnicas ORMs ou "whatever", se o problema que eles estao tendo la no Delphi ou VB6, pode ser contornado facilmente com uma Proc.

VOCE TEM MEU VOTO por fazer com que todos que leem seu post neste momento, sejam pessoas que estao liderando equipes ou preocupadas com seu futuro em descobrir novas tecnicas de desenvolvimento agil e rapido, QUE PAREM E SE PERGUNTEM SE ESTAO NO CAMINHO CERTO... e PESQUISEM mais sobre o assunto, repito, como voce bem o fez.

POREM, NAO VOU DEIXAR DE DEFENDER O USO DE STORED PROCEDURES, em ambientes onde esta seja a solucao mais conveniente, diante das circunstancias encontradas.

Eh isso ai, parabens e continue assim!

Abracos,
Pericles Sevegnani.

******************** INTRODUÇÃO ********************

Olá Giovanni,

Desculpe-me pela extensa sequencia de comentários, que juntos são muito maiores que o texto do seu próprio post. Porém, explicações detalhada são necessárias para tentar evitar, ao máximo, qualquer mal entendido nas minhas considerações. Eu estarei apresentando várias informações e comentando integralmente todas as proposições do seu último comentário até este momento, que foi direcionado a mim e que ocorreu no dia 5 de agosto de 2010, às 18:59.

Quando eu resolvi colocar comentários neste post, eu estava imaginando ter um debate técnico que pudesse ser construtivo para nós mesmos e para os leitores. Ou seja, eu estava esperando que os seus comentários tivessem um embasamento teórico que pudesse sustentar a validade das suas convicções apresentadas no post e evidenciadas na conclusão: “Joguem as procs no lixo, programem com ORMs (ou bancos NOSQL), e sejam produtivos.”. Porém, é simples perceber que você tem ignorado os principais questionamentos nos meus comentários que descrevem as contradições entre o que você tem escrito no post e nos comentários. Esta atitude leva a pensar que você não tem argumentos técnicos para justificar a sua hipótese. Afinal de contas, se você tem argumentos técnicos, então porque não responder aos questionamentos diretamente, sem rodeios, assim como estou fazendo quando cito os seus comentários.

Não adianta ficar se gabando, com citações de padrões de projeto e boas práticas de desenvolvimento, se você é incapaz de usá-los para apresentar uma solução melhor para o cenário que foi proposto. É fácil observar, pelos comentários de outras pessoas neste post, que esta sua atitude é suficiente para convencê-los que o uso de stored procedures nunca é uma boa opção. Porém, para convencer a mim, e a outros profissionais de TI que não se contentam somente com o fato do Giovanni Bassi achar que devemos jogar as stored procedures no lixo, você precisará apresentar argumentos teóricos suficientes para sustentar a sua verdade. Talvez seja difícil para você perceber, mas você não é o único profissional de TI no Brasil que tem conhecimentos de arquitetura de software.

Com a esperança de que você argumentará tecnicamente daqui para frente, eu vou esclarecer ainda mais o contexto do cenário que estou propondo e dividi-lo em partes. Cada parte será colocada em um comentário separado. Deste modo, você poderá expor as suas ideias citando cada uma das partes para defender a sua posição contra stored procedures independente de contexto.

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 1: CENÁRIO MACRO DE UMA SITUAÇÃO REAL ********************

Olá Giovanni,

Segue uma descrição macro mais detalhadas do cenário que eu descrevi anteriormente.

Um banco de dados relacional OLTP (Online Transaction Processing) é usado na persistência dos dados em uma aplicação altamente transacional. Há tabelas centrais do modelo que rapidamente atingem uma quantidade de dezenas de milhões de registros, podendo chegar a centenas de milhões quando combinadas. É necessário gerar, em tempo real, uma relação de inconsistências entre os milhões de registros das tabelas centrais. Os metadados sobre as inconsistências são sempre os mesmos, mas as regras de negócios para encontrar os dados são dinâmicas. Se não houver inconsistências, o resultado retornado será vazio. Sendo que, quando há inconsistências, os dados que devem ser retornados para a aplicação não costumam ultrapassar a ordem de grandeza de centenas de registros. Um grupo especial de usuários, denominados supervisores, precisam analisar as informações das inconsistências para eliminá-las. O processo de aplicação das regras de negócios para encontrar as inconsistências, para análise dos supervisores, deve acontecer em tempo real e em paralelo com as transações realizadas pelas centenas de outros usuários no banco de dados. São requisitos do sistema: a garantia de que as inconsistências possam ser geradas simultaneamente para todos os supervisores, se necessário, com o melhor desempenho possível e gerando o menor impacto para os outros usuários que estão realizando transações no banco de dados.

Desta vez, observe que o cenário está um pouco mais detalhado, mas ainda corresponde a uma visão macro dos requisitos relacionados com a geração de discrepâncias para supervisores. Esta visão macro é suficiente para que um arquiteto se software possa fornecer uma solução, também macro, para tentar garantir o desempenho exigido pelos requisitos do sistema na geração de discrepâncias. Portanto, não cabe a argumentação que um colega fez num dos comentários anteriores: “Com certeza não tenho como lhe dar uma solução, pois não conheço seu diagrama de classes, a sua arquitetura do projeto, é muita vaga a ideia de criar relatorios em tempo real, com uma grande massa de dados.”. Observe que não há a necessidade de conhecer os detalhes para propor soluções macros para atender aos requisitos do cenário apresentado. E, Giovanni, você já havia entendido perfeitamente o contexto apresentado por mim, tanto que propôs duas soluções possíveis no seu comentário do dia 25 de julho de 2010.

Você escreveu no seu post:
“3.Stored Procedures ajudam a encapsular regras de negócio.
Mito. Eu posso encapsular, com mais produtividade na programação, em um modelo OO.”

QUESTIONAMENTO 1) Será que agora você poderá propor uma arquitetura, para o cenário descrito, para atender aos requisitos do sistema sem jogar regras de negócios no banco de dados, ou seja, que permita “encapsular, com mais produtividade na programação, em um modelo OO”?

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 2: UMA SOLUÇÃO POSSÍVEL COM STORED PROCEDURES ********************

Olá Giovanni,

A solução que eu usei para possibilitar a geração das relações de inconsistências, em tempo real, para os supervisores foi parcialmente similar à sua primeira sugestão, no seu comentário do dia 25 de julho de 2010. Eu também “desnormalizei” as tabelas centrais para garantir o desempenho na geração das informações de inconsistências. Porém, eu optei por criar uma stored procedure ao invés de executar um SELECT único. Em ambas as situações, as regras de negócios para encontrar as discrepâncias serão executadas diretamente no banco de dados. Sendo que, com uma stored procedure eu posso executar as regras de negócio de uma forma mais simples que com uma única consulta, que pode ser tornar extremamente complexa.

Na descrição do cenário, eu comentei que as regras de negócios para encontrar as discrepâncias são dinâmicas. Portanto, eu criei stored procedures separadas para cada regra de negócio. No arquivo XML de configuração do componente responsável pela execução das stored procedures, dentre as outras tarefas de acesso a dados, eu coloquei pares de chave/valor com o mapeamento dos nomes das regras de negócios para os nomes das stored procedures correspondentes. Todas as stored procedures recebem um único parâmetros, que é o ID do supervisor. Ainda há outro par chave/valor no arquivo XML de configuração para definição da regra de negócio a ser usada.

Quanto à solução de SELECT único que você apresentou no seu comentário do dia 25 de julho de 2010, eu fiz dois questionamentos no meu comentário do dia 26 de julho de 2010. Estes questionamentos não foram respondidos. Sendo assim, eu estou copiando-os novamente abaixo.

QUESTIONAMENTO 1) Na solução proposta por você (SELECT único), onde está o uso do modelo OO?

QUESTIONAMENTO 2) Como eu vou usar os recursos de POO, como polimorfismo, por exemplo, para modificar as regras de negócios para filtragem das discrepâncias?


Abraços,

Rogério Moraes de Carvalho

******************** PARTE 3: SOLUÇÃO POSSÍVEL NO CONTEXTO DE POO ********************

Olá Giovanni,

Na realidade, eu preferia ter colocado as regras de negócios para encontrar as inconsistências em classes de negócios de modo a poder usar recursos de POO e de padrões de projeto para acrescentar novas regras de negócios dinamicamente. E mais recentemente, eu ainda poderia usar a nova biblioteca MEF (Managed Extensibility Framework) do .NET Framework 4, para simplificar o design da extensibilidade dos componentes com as regras de negócios para encontrar as inconsistências.

Porém, no contexto apresentado, é inviável usar um framework de ORM para recuperar milhões de registros do servidor de banco de dados para o servidor de componentes. Além de gerar um trafego enorme entre os servidores, eu ainda teria milhões de objetos criados na memória do servidor de componentes. E estes milhões de objetos teriam que ser passados para uma instância de uma classe com uma regra de negócios para encontrar as inconsistências. Além de gerar um intenso trafego de rede entre os servidores de banco de dados e de componentes e um intenso uso de memória no servidor de componentes, eu ainda exigiria muito processamento para gerar a relação de inconsistências. Sendo que os servidores de banco de dados relacionais mais modernos possuem engines otimizados para trabalhar com grandes volumes de dados. Além de uma série de recursos disponíveis, como indexação de colunas de acordo com as minhas necessidades de consulta, dentre outros recursos.

Observe que eu não estou dizendo que somente é possível trabalhar com grandes volumes de dados em bancos de dados relacionais. Existem outras formas de persistir os dados, como em bancos de dados orientados a objetos e bancos NoSQL, por exemplo. Porém, os bancos de dados relacionais estão sendo usados intensamente e evoluídos há décadas. Para ser mais preciso, a primeira implementação relativamente confiável do modelo relacional foi feita em 1968 na universidade de Michigan: o Micro DBMS. Ou seja, a primeira implementação confiável tem mais de 40 anos.

Os bancos de dados orientados a objetos fornecem um modelo no qual a informação é persistida na forma de objetos. Portanto, teoricamente, eles são muito mais voltados para trabalhar com o paradigma de orientação a objetos que os bancos de dados relacionais. Você chegou a citar os bancos de dados orientados a objetos no último parágrafo do post “Repositórios e a abstração do acesso aos dados” (unplugged.giggio.net/.../...cesso-aos-dados.aspx), escrito no final de janeiro de 2009. Porém, os bancos de dados orientados a objetos têm uma participação muito pequena em sistemas de processamento de dados. Em Brasília, eu conheço um único caso de uso de bancos de dados orientados a objetos onde há gerenciamento de um volume considerável de dados. Eles usam o InterSystems Caché e não estão satisfeitos, devido a problemas constantes, inclusive de perda de índices. Há alguns anos, eles estão migrando gradativamente os dados para um banco de dados relacional. Porém, eles têm um grande volume de dados no legado Caché e a migração ainda deve perdurar por mais alguns anos.

Atualmente, a moda são os bancos de dados NoSQL (Not Only SQL), como você mesmo citou no seu post: “É isso. Joguem as procs no lixo, programem com ORMs (ou bancos NOSQL), e sejam produtivos.”. Este termo foi usado pela primeira vez em 1998. Atualmente, existem notáveis implementações em produção, como o BigTable do Google e o Dynamo da Amazon. Porém, somente no início do ano passado (2009), Eric Evans reintroduziu o termo em um evento para discussão de bancos de dados distribuídos open-source. Ele é autor do livro “Domain-Driven Design: Tackling Complexity in the Heart of Software”, considerado uma referência em DDD.

QUESTIONAMENTO 1) Já que uma das suas sugestões é usar bancos de dados NoSQL, você poderia explicar uma solução para atender ao cenário descrito com uso de um banco de dados NoSQL que você conheça? (A não ser que você esteja sugerindo o uso de uma categoria de banco de dado, no caso NoSQL, sem conhecimento de causa.)

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 4: ETL ********************

Olá Giovanni,

Você escreveu: “Ok, você não concorda comigo que o caso é parecido com ETL. Eu aceito isso, vamos ter que concordar em discordar. Eu acho que é arquiteturalmente parecido e que você está se pegando em detalhes. A transformação está acontecendo, e o load também.”

Se esta é realmente a sua opinião, eu acho que você precisa revisar o seu conceito de ETL (Extract, Transform, and Load). Afinal de contas, é fácil verificar que o cenário que eu apresentei não representa um caso de ETL. Basta você comparar o cenário com a explicação da Wikipedia, que você mesmo forneceu um link no seu post. Ou seja, eu acredito que você tenha lido e concordado com o conceito apresentado na Wikipedia. A não ser que você indique leituras complementares em seus posts sem ler antecipadamente o que está indicando.

Depois, você pode ler novamente a minha argumentação feita no meu comentário do dia 26 de julho de 2010. Você simplesmente passa por cima dos meus comentários e afirma: “Eu acho que é arquiteturalmente parecido e que você está se pegando em detalhes.”.

QUESTIONAMENTO 1) Basta você achar que é parecido com ETL que está tudo resolvido, sem nem haver a necessidade de rebater tecnicamente os meus argumentos?

QUESTIONAMENTO 2) E você acha que, assim como você, eu devo fazer uma análise superficial e passar por cima do conceito de ETL para não ficar “pegando em detalhes”?

Observe que num primeiro comentário, você afirmou: “a semelhança do processo que você está propondo com o ETL é imensa”. Num comentário posterior, você já ponderou e desistiu da imensa semelhança, afirmando: “Eu acho que é arquiteturalmente parecido e que você está se pegando em detalhes.”. Porém, vamos verificar o absurdo que é você dizer que o contexto que eu estou descrevendo é parecido com ETL. Nos próximos três parágrafos, eu vou comentar as etapas do processo de ETL, no contexto que eu apresentei, de acordo com o raciocínio que você colocou nos seus comentários.

EXTRACT – No seu comentário do dia 25 de julho de 2010, você afirmou: “1) Não há Extract, os dados já estão no banco.”. Ou seja, você admite que não haja a etapa de extração, mas mesmo assim acha o processo parecido com ETL.

TRANSFORM – No contexto apresentado, há uma análise de milhões de registros para se encontrar inconsistências que satisfaçam a uma regra de negócios. Se estas inconsistências não existirem, haverá retorno de um resultado vazio. Porém, quando estas inconsistências existirem, elas não costumam passar da ordem de grandeza de algumas centenas de registros. No seu comentário do dia 25 de julho de 2010, você afirmou: “2) Há a transformação.”. E no comentário do dia 5 de agosto de 2010, às 18:59, você afirmou: “A transformação está acontecendo, e o load também.”. Ou seja, você está afirmando que uma análise em um grande volume de dados para encontrar ou não inconsistências é uma transformação no sentido do conceito de ETL. Então, para você, se não houver inconsistências, então haverá uma transformação que produzirá um resultado vazio para a próxima etapa do processo de ETL, a etapa de carga.

QUESTIONAMENTO 3) Você poderia justificar com mais detalhes porque acha que no cenário descrito há uma transformação no sentido do conceito de ETL?

LOAD – No contexto apresentado, o resultado da aplicação das regras de negócios para encontrar as discrepâncias é carregado na memória e enviado para a aplicação cliente. Então, este resultado com as discrepâncias será apresentado para os supervisores. Quando as inconsistências forem eliminadas pelos supervisores, o resultado será vazio. No seu comentário do dia 25 de julho de 2010, você afirmou: “3) Há a carga para consulta resultado da transformação.”. Ou seja, você está afirmando que uma carga de dados na memória é um processo de carga no sentido do conceito de ETL. Se for assim, então a referência que você passou sobre ETL na Wikipedia está incompleta: “Loading it into the end target (database or data warehouse)”. Talvez você queira editar o conteúdo da Wikipedia para colocar: “Loading it into the end target (database or data warehouse or memory)”. E no comentário do dia 5 de agosto de 2010, às 18:59, você afirmou: “A transformação está acontecendo, e o load também.”.

QUESTIONAMENTO 4) Você poderia justificar com mais detalhes porque acha que no cenário descrito há uma carga no sentido do conceito de ETL?

Se você justificar teoricamente e de forma consistente os quatro questionamentos que eu fiz acima, daí sim eu poderei aceitar e, como você disse, “vamos ter que concordar em discordar”. Porém, sem uma explicação teórica da sua parte, eu não consigo nem mesmo “concordar em discordar” com você.

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 5: NUVEM E BASE ********************

Olá Giovanni,

Você escreveu: “Mas isso é até menos importante. Sinto que você descarte a opção de trabalhar online, mas de fato esse é o comportamento da maioria das pessoas, é um comportamento conservador. Essa é a abordagem para qual o mercado está caminhando, ainda que devagar.”.

Portanto, você acha que são conservadores os profissionais que, assim como eu, utilizam as tecnologias e tendências mais recentes disponíveis no mercado de forma consciente e num contexto apropriado. Você deve achar que são melhores profissionais aqueles que, assim com você, afirmam coisas como: “É isso. Joguem as procs no lixo, programem com ORMs (ou bancos NOSQL), e sejam produtivos.”. E, no futuro, se surgir um movimento NoORM a favor de uma tecnologia XYZ, você deve escrever um post afirmando: É isso. Joguem os frameworks ORM no lixo, programem com a tecnologia XYZ (ou frameworks NoORM), e sejam produtivos.

QUESTIONAMENTO 1) Você considera que profissionais devem embarcar indiscriminadamente em cada nova tecnologia lançada e que profissionais que, assim como eu, avaliam as novas tecnologias antes de usá-las na prática são conservadores?

Depois, você escreveu: “O mundo não é batch, é online. Somos BASE (Basically available, soft state, eventually consistent). A nuvem caminha pra isso e é uma estratégia excepcional para escalabilidade. Veja o artigo do Otavio Coelho: blogs.msdn.com/.../acid-x-base.aspx.”

O artigo que você citou no seu comentário, destacado acima, que foi escrito pelo Otavio Pecego Coelho, aborda uma característica da plataforma Windows Azure, que é a plataforma da Microsoft para computação na nuvem: http://www.microsoft.com/windowsazure/. Mais especificamente, o artigo aborda o conceito de consistência eventual, que também é conhecida como “BASE (Basically Available, Soft state, Eventual consistency)”. Este é um conceito oposto ao conceito ACID (“Atomicity, Consistency, Isolation, Durability”), que se refere a um conjunto de propriedades para garantir que operações transacionais sejam processadas de forma confiável.

Eu não entendi o seu real propósito em citar um artigo de Windows Azure no contexto do nosso debate. Parece-me mais uma estratégia sua para desviar a atenção do leitor do que realmente está sendo debatido. Ou seja, a sua posição contra stored procedures independente de contexto.

Você afirmou: “A nuvem caminha pra isso e é uma estratégia excepcional para escalabilidade.”. E eu concordo com você. Porém, a nuvem não deve ser usada indiscriminadamente. Deve haver uma análise criteriosa para se pesar os prós e os contras para cada contexto. Por exemplo, existem casos em que o sigilo dos dados exige que o armazenamento seja feito em servidores próprios seguindo uma série de normas rígidas e não permitindo o uso da nuvem. Inclusive, esta restrição pode ser definida em contrato.

De qualquer modo, mesmo que você desenvolva um sistema para ser executado na nuvem, ainda assim, você precisa definir uma arquitetura que satisfaça os seus requisitos. Afinal de contas, uma arquitetura ruim vai provocar desperdício de dinheiro pela alocação de mais recursos nos servidores da nuvem. E, dependendo da arquitetura, nem mesmo os servidores na nuvem vão resolver os seus problemas de desempenho. Não adianta alocar uma infinidade de recursos de servidores se a arquitetura do sistema não foi projetada para alta escalabilidade.

QUESTIONAMENTO 2) Por acaso, você está sugerindo que usar computação na nuvem é suficiente para resolver problemas de desempenho independente de contexto?

Eu não poderia deixar de comentar sobre uma das partes da plataforma Windows Azure: o SQL Azure Database (http://www.microsoft.com/windowsazure/sqlazure/). Ele é um serviço de banco de dados relacional, baseado na nuvem, construído com tecnologias do SQL Server. De acordo com a Microsoft, ele fornece serviço de banco de dados de alta disponibilidade, escalabilidade e multi-tenant (preparado para armazenar dados de múltiplos clientes que estão alugando o serviço). O SQL Server Azure corresponde a um RDBMS (Relational Database Management Services) e suporta a criação, acesso e manipulação de tabelas, views, índices, roles, stored procedures, triggers e funções. Observe que, até na plataforma de nuvem da Microsoft, você pode usar stored procedures.

Uma vez que você citou a plataforma de computação na nuvem Windows Azure da Microsoft e o conceito BASE (Basically Available, Soft state, Eventual consistency), eu acredito que você tenha pensado em uma arquitetura para atender aos requisitos do cenário apresentado em nosso debate. A não ser que você ache que o simples fato de desenvolver um sistema para a nuvem seja suficiente para atender aos requisitos de desempenho de um sistema.

QUESTIONAMENTO 3) Você poderia sugerir uma arquitetura na plataforma Windows Azure, usando o conceito BASE (Basically Available, Soft state, Eventual consistency), para atender os requisitos de desempenho no contexto do cenário descrito na PARTE 1?

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 6: COMMAND-QUERY SEPARATION ********************

Olá Giovanni,

Você escreveu: “Além disso, sugiro investir um tempo em Command & Query Separation, que propõe exatamente isso, além de algumas coisas a mais para resolver o problema de performance, consistência, reporting e batches.”.

Então, você sugere um princípio, de forma desconexa do cenário que eu apresentei, e está tudo resolvido. Pelo seu comentário, está parecendo que este é um princípio mágico que resolverá o meu “problema de performance, consistência, reporting e batches.”.

Eu não precisarei investir um tempo no princípio que você citou, exatamente porque eu li o livro “Object Oriented Software Construction, 2nd Edition”, que foi escrito pelo Bertrand Meyer. Para contextualizar os demais leitores, Bertrand Meyer foi o criador da linguagem de programação Eiffel e é um consultor, autor e acadêmico especializado em linguagens de programação. Ele é especialista em POO (Programação Orientada a Objetos). O seu livro “Object-Oriented Software Construction” é considerado, por muitos, um dos melhores trabalhos de apresentação de casos de POO. Em 1988, neste livro, ele apresenta o famoso “Open-Closed principle”, que afirma: “Modules should be both open and closed.”. A contradição do princípio é proposital. Em 1996, o Robert C. Martin (Uncle Bob), escreveu o artigo “The Open-Closed Principle” (www.objectmentor.com/resources/articles/ocp.pdf), onde expôs detalhadamente o princípio da seguinte forma: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”.

O princípio citado pelo Giovanni Bassi, “Command-Query Separation principle”, é citado na página 751 do livro “Object Oriented Software Construction, 2nd Edition”. Este princípio afirma que “Functions should not produce abstract side effects.”.

QUESTIONAMENTO 1) Você poderia citar como imaginou o uso deste princípio para resolver o “problema de performance, consistência, reporting e batches” no contexto do cenário que eu descrevi na PARTE 1?

É impressionante como você consegue dizer uma coisa numa frase e se contradizer logo na frase seguinte. Eu acabei de comentar esta sua frase: “Além disso, sugiro investir um tempo em Command & Query Separation, que propõe exatamente isso, além de algumas coisas a mais para resolver o problema de performance, consistência, reporting e batches.”. E, na frase seguinte você disse: “Os problemas que você cita para o online não são problemas, mas parte da natureza do negócio que você está resolvendo. Uma arquitetura que suportasse tal modelo seria a mais fiel, e portanto, mais adequada.”.

QUESTIONAMENTO 2) Se “não são problemas”, então porque você se referiu como “problema” na sua frase anterior?

Ficou claro na sua frase anterior que você já havia entendido o contexto em que eu estava usando a palavra “problema”. Em todas as vezes que me referi ao contexto que descrevi como um problema, eu estava abordando o problema de desempenho. Mais uma vez, você tenta desviar a atenção do leitor para fugir do debate técnico.

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 7: REPOSITORY PATTERN ********************

Olá Giovanni,

Você finalizou o seu último comentário direcionado a mim com a frase: “Quanto ao uso do repository pattern, que você cita em seguida em outro comentário, não foi feito para o uso de reporting, e muitos entendem que entidades, e portanto repositórios, não são adequados a exibição de dados em tela. Isso vai gerar alguns problemas, que não vale a pena entrar aqui...”.

Este seu comentário final é tão absurdo que até parece que você leu outro comentário, que não o meu. Abaixo, eu destaquei o texto que eu citei sobre o padrão de repositório: “Atualmente, eu tenho usado o Entity Framework 4 ou o NHibernate for .NET 2.0.1 para manipular a persistência de objetos .NET de e para bancos de dados relacionais. Além disto, eu uso o padrão de repositório para ajudar a encapsular a consulta dos dados e a lógica de persistência. Deste modo, eu posso abstrair do restante da aplicação os detalhes de implementação da persistência de dados.”

QUESTIONAMENTO 1) Onde você leu que eu uso o padrão de repositório para reporting e onde eu falei que uso entidades do repositório para exibição de dados na tela?

É impressionante a sua capacidade de distorcer as afirmações com o objetivo de fugir do debate técnico.

Abraços,

Rogério Moraes de Carvalho

******************** PARTE 8: CONCLUSÃO ********************

Se você realmente quer manter um debate técnico a respeito do assunto do uso ou não de stored procedures no desenvolvimento de sistemas, então você precisa procurar apresentar as suas ponderações de forma clara e sem desviar do debate. Eu acredito que a maioria dos leitores do seu post “Mitos sobre stored procedures” estão interessados em analisar os prós e contras das stored procedures. Você está tendo a oportunidade de fazer um embasamento teórico para justificar a sua posição polêmica. Em geral, não será suficiente você fazer uma afirmação sem embasamento teórico para convencer os profissionais de TI com conhecimento técnico e personalidade.

Eu tive a melhor das intenções quando apresentei o contexto de uma aplicação em que usei stored procedures para não ter problemas de desempenho. Eu estava esperando com isto ter um debate saudável e repleto de informações técnicas. Eu imaginava que você não poderia propor uma solução, no contexto do cenário apresentado, sem uso de stored procedures e sem jogar regras de negócios no banco de dados, que pudesse ter um desempenho tão bom quanto uma solução com uso de stored procedures. Mas, não foi isto que aconteceu. Você ficou se esquivando do debate técnico o tempo todo e tentando desqualificar os meus comentários. Citando princípios soltos, como se somente você tivesse conhecimentos dos mesmos. Querendo passar um ar de superioridade técnica para convencer o leitor das suas convicções, ao invés de argumentar teoricamente. Você gosta de citar termos novos, que foram introduzidos ou reintroduzidos há pouco tempo, como NoSQL e BASE (Basically Available, Soft state, Eventual consistency), sem detalhar o uso da tecnologia no contexto do debate. Você coloca as tecnologias como mágicas e capazes de resolver os problemas discutidos num debate sem justificativas e nem contextualizações. E você também gosta de fazer afirmações absolutas sem ter argumentos sólidos para tentar justificá-las. Em geral, somente a atitude de se fazer uma afirmação absoluta já é um grande passo para uma posterior argumentação fracassada.

QUESTIONAMENTO 1) Por que, ao invés de citar as novas tendências tecnológicas de forma solta e desconexa em seus textos, você não descreve como aplicar estas novas tecnologias nos contextos das discussões? (Talvez, este seja um recurso para confundir os leitores menos preparados ou para fugir do debate técnico quando os seus argumentos são fracos ou simplesmente insuficientes para sustentar as suas convicções.)

Eu espero que você mude a sua atitude e que possamos ter um debate construtivo e técnico. Eu sugiro que você cite os meus comentários pelos títulos, “PARTE 1: INTRODUÇÃO”, por exemplo, e faça as suas considerações respondendo aos questionamentos destacados no texto do seguinte modo: “QUESTIONAMENTO 1”, “QUESTIONAMENTO 2”, etc. Ou então, simplesmente ignore todos os questionamentos e deixe as conclusões por parte dos leitores.

Abraços,

Rogério Moraes de Carvalho

Pessoal,

Tudo tranquilo? Lí o post, os comentários e achei tudo muito interessante.

Refleti muito e acabei de enviar um email para meu chefe cancelando o treinamento de Performance Tuning. Troquei por um de mergulho em Angra dos Reis (litoral sul do Rio de Janeiro).

Quando voltar vou dropar TODAS as stored procedures e vou passar a sair no meu horario (17:00 horas). Os Arquitetos de Software e Desenvolvedores da empresa que trabalho que se virem com ORM e OOP para as regras de negocios que, até eu chegar do curso de mergulho, estarão em Stored Procedures.

Abraços,
Alexandre Lopes

Acho que o problema todo foi o "Joguem as procs no lixo".. isso deixou o pessoal "sentidinho".....

Na minha opinião, muita gente trabalha com SP graças aos legados e tem que aturar essa situação (aturar porque, em geral, são "zilhões" de SP cheias de regras, cada uma chamando outras 5.. enfim... uma ZONA!)

Mas se você precisa delas por causa daquela aplicação com dezena de bilhões de registros e elas te atendem bem pra isso... perfeito!

Olá Robson,

Não posso falar pelos outros. Mas, pelo menos no meu caso, o principal problema está na condenação de uma tecnologia independente de contexto.

Eu espero poder ler comentários de outros profissionais com sugestões de arquiteturas alternativas, contextualizadas no cenário descrito e que satisfaçam os requisitos de desempenho do sistema, sem haver a necessidade de jogar as regras de negócios no banco de dados.

Abraços,

Rogério Moraes de Carvalho

Sres. É muito bom ver uma discussão onde os pontos de vista são ferrenhamente defendidos.
Tenho minha opinião e por incrível que pareça tem sido muito bem aceita em TODOS os debates presenciais que estive involvido, e não são poucos.
Trabalho a 20 anos em uma empresa onde a segurança da informação vem em primeiro lugar, em seguida a necessidade de performance dos produtos de TI.
Não vou aumentar ainda mais o debate sobre os 5 pontos apresentados pelo Giovanni, acredito sim que exite espaço para tudo, a generalização de o métodos "salvador da pátria para todos os modelos" é que eu não concordo.
Em nossa empresa usamos proc para tudo, inicialmente haviam dois grandes motivos, hoje com o 2008R2 existe um gigantesco motivo e um motivo não tão grande.

Primeiro a performace, o não tão grande hoje, e a minha opinião é formada em cima de dados experimentais, realizados e testados com métodos ideais de repetição para avaliação.
O uso de proc são mais performaticas sim quando da execução das instruções do que os ad-hoc, e esta diferença é MUITO grande na maioria das versões de bancos, a excessão do 2008 R2 em que esta diferença não é TÃO grande porque está armazenando em cache a execução dos ad-hoc, e SE seu servidor tiver MUITA memória disponível ele vai manter este cache tempo suficiente para reutilizar o código.

Segundo o controle. Quando digo o controle, não digo sobre a segurança do método ou modelo de desenvolvimento, mas digo sobre as pessoas, a parte mais vulnerável de qualquer processo.
Sei que existem uma gama infindável de métodos de controlar o acesso aos dados nos códigos, mas nenhum é eficiente quando o programador intencionalmente deseja violar as regras.
Para conseguir controlar esta falha, somente com a checagem do acesso por outra pessoa, e neste caso quem é o responsável por manter a informação em uma instituição séria e zelar por ela? O DBA.
Ora, com o uso de proc, o DBA tem o TOTAL controle das informações que trafegam pelso seu objeto de responsabilidade, e este cara pode ser responsabilizado pelas informações com preceitos legais inclusive.

Ao contrário, sem o uso de proc, o DBA primeiro vai ter que liberar o acesso correto a todas as tabelas e/ou campos em que o sistema necessite algum tipo de acesso, enquanto que no uso de proc este tipo de controle é extremamente simples. Assim vou começar tendo que contratar mais DBA, olha o risco aumentando.
Depois, o DBA fica completamente cego sobre o que está acontecendo com o banco de dados, o que o programador está fazendo e COMO ele está fazendo. E mais, caso haja um problema na execução, a única ação possível por parte do DBA é derrubar a aplicação, nem análise do procedimento ele consegue fazer, ficando completamente DEPENDENTE do programador para atuar na solução.

É óbvio que o uso de modelos ad-hoc são mais rápidos e eficientes quando olhados do somente do lado do PROGRAMADOR, mas quando olhados do lado da INSTITUIÇÃO que zela pelas suas informações é um aumento gigantesco do RISCO, devo reafirmar, o risco não é pela tecnologia envolvida, mas pelas pessoas que a usam.
Com proc, todo o controle das informações ficam com o DBA, inclusive este pode nem abrir a sua estrutura de banco à equipe de desenvolvimento, que convenhamos é uma equipe de alta rotatividade, quando comparada com a o grupo de DBA.
Bem a idéia era trazer a visão de alguém um pouco mais gerencial e não somente técnico da área de Desenvolvimento ou DBA ou mesmo de Redes.
Quando olhando acima deste trio que por sinal vivem discutindo, o que tem que sobreviver é a instituição, com seus dilemas de preservação da informação e também velocidade na produção.
Como conclusão particular, e neste ponto não tento influenciar outros apenas apresentar a minha, os 5 pontos apresentados como mito pelo Givanni PODEM até ter deixado de ser verdade absoluta com a evolução dos BD e dos modelos de programação, mas são sim VERDADES quando o foco da empresa é preservação da informação sob sua guarda. Quando a empresa ou trabalho em questão possui apenas o foco produtivo da entrega do sistema, com certeza o uso dos 5 pontos é um MITO.
Resta saber individualmente que tipo de produto é pretendido e qual o foco da sua empresa.

Gente, milhões de desculpas pelo exceSSão... E outros erros e português...

Alexandre, mas seguindo essa linha, também não é arriscado pra empresa deixar tudo na mão do DBA, o guardião-magnânimo dos dados?

O risco sempre vai haver em qualquer ocasião, mas isso é aquela velha briga "DBA X Dev".

[]s

Boa Robson, é sim, o risco sempre vai existir, o ideal é reduzir ao máximo o risco, e o risco restante ser terceirizado (Seguro por exemplo) ou no caso de DBA´s conseguir aplicar a culpabilidade, ou seja:

Quem é a equipe responsável pelos dados da instituição armazenadas em banco de dados? Os DBA´s. Na melhor hipótese somente eles devem possuir poderes para alterar as informações de forma não programática.
Sendo assim se algo de errado acontecer, a culpa pode ser aplicada a esta equipe.

Outra característica é que a equipe de DBA normalmente é bem menor que a de desenvolvimento, esta é uma característica que diminui o risco. A equipe de DBA também possui menos rotatividade, outra característica que diminui o risco.

Mas para poder garantir que somente os DBA´s podem fazer manupulação dos dados, a equipe de DBA deve ter controle total sobre as transações, este é um dos motivos do porque aqui usamos proc para tudo.
Se o DBA subiu uma proc para produção e não estudou ela direito e ela fez um grande estrago, a culpa final é do DBA e ele não tem como reclamar disso.
Cada um com sua responsabilidade.

No caso do uso de acesso direto aos DB, o DBA pode se eximir de culpa porque não tem o controle total. E ainda o universo de pessoas com poderes para fazer algo que gere problemas é aumentado, o que dificulta o controle.

Esta é minha opinião, não acredito que este seja o forum mais adequado a este dipo de visão mais gerencial. A idéia era apenas apresentar a visão, deixando o princípio que o que importa é a instituição, e que existe espaço para todos os métodos, desde que adequados ao modelo que a instituição deseja.

Deixa aquele pessoal de java, aquele que não fica usanso blog para se promover, ler essa discussão.

Enquanto o mundo .Net está achando algumas coisas novas , tem um pessoal, aquele que não usa blog nem boné do fornedor, que usavam essas coisas no inicio dos anos 2000.

Eu sou um deles e não resisti !!!!!!

Oi Giovani,

As operações clássicas de INSERT, UPDATE e DELETE são preparadas para grande quantidades de operações com baixos volumes de dados. Operações de ETL normalmente são opostas e representam grandes volumes de dados com algumas poucas operações (normalmente cargas agendadas). Essa diferença faz com que cargas baseadas em operações e codificações tradicionais (ADHOC queries e Stored Procedures) sejam inadequadas, pois, normalmente não são performáticas.

Claro que cargas relativamente pequenas vão se sair bem com SPs, mas no geral, grandes volumes irão demandar uma ferramenta de ETL a parte, pois, processos de ETL baseado em Queries, Stored Procedures, etc não costumam ser muito escaláveis. Nesse caso podemos optar por ferramentas como o DTS ou o SSIS da Microsoft ou ainda soluções de outros fabricantes como o Data Stage (IBM), Power Center (Informatica), Pentaho (essa é free), etc.

Essa análise não está restrita ao SQL Server. Aplica-se a qualquer banco de dados. Os pontos sobre ETL são muito bem detalhados no clássico "The Data Warehouse ETL Toolkit" do Ralph Kimball. No link que passei tem outras considerações (http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1026.entry)

[ ]s,

Gustavo Maia Aguiar

Show de Bola..adorei o Post...espero que muita gente parta pra idéia de "jogar as stored procedures no lixo"... Terei muito trabalho depois para arrumar

A impressao que tenho é que existe um medo por parte de certos DBAs perderem o emprego...sei não...
Sem dizer que ficar nesse pensamento de "tem que ser SP, tem que ser SP, pq é mais seguro e mais eficiente (e pq eu trabalho assim ha mais de 20 anos)" me parece falta de vontade de enxergar que os tempos mudaram....