Sobre Aplicações Programadas em Bancos de Dados
25/05/2010 00:00
0
Turma,

Surgiu uma discussão sobre desenvolvimento de aplicações dentro de bancos de dados, no tópico "O que você não gosta do Grails?", e gostaria de compartilhar minha experiência como arquiteto de aplicações corporativas.

Seguinte pessoal, é fato que existem cenários em que fazer a aplicação dentro do banco de dados é a única saída em baixa plataforma. Mas só existem porque são a única saída, e não porque é a melhor saída.

São casos extremos, não devem ser tomados como base, mas existem!

Vou citar pra vocês dois grandes exemplos:

1. Necessidade crucial de vazão (throughput) do processamento.

Um exemplo deste cenário é a bilhetagem (processamento de contas) em prestadores de serviços (telefone,água,luz,etc.). Problema: Eu preciso processar um enorme volume de dados dentro de X dias para enviar a conta a pagar pra todos os clientes. A minha restrição aqui não é manutenibilidade, mas sim desempenho e vazão, pois o volume de processamento não pode esperar senão a conta atrasa! E ainda tem a segurança dos dados! Caso não seja no banco de dados (na maioria das vezes Oracle), vai ter que ser num mainframe. Acredite!

2. Compartilhamento de regras de negócio entre várias aplicações.

Um exemplo deste cenário são os bancos e financeiras, que possuem aplicações em diversas plataformas (cobol, delphi, java, .net) que devem possuir as mesmas regras e mesma segurança nas consultas. Seja na frente do caixa, seja no internet banking, nos quiosques, etc. Na maioria das vezes os cálculos são feitos em cima de enormes quantidades de dados (orientados a dados e não a objetos) então vale sim a pena trabalhar com Stored Procedures pois em muitos casos eu vi um aumento muito grande, por volta de 10x mais rápido! Tem que existir pelo menos um uso pra isso né?

Bom, daria pra fazer isso com uma arquitetura distribuída com EJB, certo? Errado! EJB é só pra aplicações Java, sem contar que EJB2 é pior pra dar manutenção do que Stored Procedure. Acreditem!

Então porque não utilizar SOA? Bom, SOA é um estilo arquitetural recente e TI em banco e financeiras foi onde de fato nossa área começou a crescer e agregar valor ao negócio, isso há décadas atrás. O que foi e ainda é muito utilizado como estilo arquitetural são bancos de dados como uma espécie de "barramento de dados" (similar a um ESB), rodando em Storages, onde várias aplicações consomem dados com regras de negócio. E como toda plataforma/linguagem, seja antiga ou nova, conecta bem em bancos de dados, esta se opção se tornou viável, pois os problemas de manutenibilidade são menores que os problemas de interoperabilidade. E mesmo hoje em dia, ao utilizar arquitetura SOA, dependendo da tecnologia aplicada, algumas operações se tornam inviáveis pois serializar/deserializar XML e transportar via rede em mais de uma camada física pode ser custoso.

Interessante nisso é perceber que muito do que os bancos de dados cresceram em funcionalidade, se deve à necessidades reais de bancos, financeiras, telecoms, dentre outros cenários onde o volume de dados é estupidamente alto. É um contexto particular que deve ser levado em consideração.

O grande problema é que a TI cresceu de lá e desceu pra cenários onde os sistemas não tem um volume tão gigantesco de dados, e portanto herdaram várias característica e estilos arquiteturais não indicados para um contexto "menor".

Bom galera, tirando estes dois contextos, ainda não vi mais NENHUM motivo pra desenvolver aplicações dentro do banco, com Stored Procedures, SQL programado e todo aquele código estruturado de 20 anos atrás. Fazer isso pra seu banco de 1GB é matar formiga com bala de canhão.

Mas entendam: tudo tem um motivo!

O que carece muito na nossa área é CONTEXTO!

Infelizmente pouca gente defende um ponto de vista bem contextualizado. Acreditam que o que funcionou em um contexto, vai funcionar pra qualquer contexto.

Grande abraço!
Tags: Off-Topic


0
E não é que eu concordo em gênero, número e grau? <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->

Sabe, na realidade eu vou um pouco além: acho que a cada dia que se passa, o SGBD relacional &quot;grandão&quot; como um Oracle, SQL Server ou Ingres acabam se mostrando verdadeiras bazucas para se matar formigas. Não que sejam bons, são ótimos: mas bancos menores como um Firebird ou SQLite resolvem o problema muito bem.

Outro fator que tenho observado de uns anos pra cá é a substituição da abordagem &quot;aplicação baseada em SGBD&quot; por arquiteturas como REST e SOA (entre as duas, confesso preferir 100 vezes mais a primeira).

E com a &quot;aparição&quot; da &quot;cloud&quot; (que sempre esteve presente mas agora estão tentando nos vender como se fosse algo novo), este papo do &quot;vou centralizar minha lógica de negócios no SGBD&quot; virou balela, porque a lógica de negócios já é centralizada na aplicação.

No final das contas, o que mais me assusta mesmo é o determinismo linguístico no qual alguns profissionais caem. Sabe: SGBD é ótimo. É lindo. É maravilhoso, mas aplicar um modelo como este em tudo é a mesma coisa que tentar desparafuzar um parafuso com martelo. Há situações que simplesmente não rola.

É por isto que estou muito otimista com esta &quot;moda&quot; noSQL (not only), pois com ela tenho visto muita gente abrindo a consciência pra outras possibilidades além do modelo tabular que, convenhamos, não é o mais adequado a todas as situações. Principalmente se nos lembrarmos que vivemos em um mundo com BEM mais de duas dimensões, não é mesmo?


0
Excelente follow-up! =)

O bacana do movimento NoSQL é trazer alternativas interessantes para cenários que não estavam bem atendidos, principalmente aplicações Web com centenas/milhares de usuários simultâneos, que vinham sendo atendidos pela alternativa MySQL/Memcached.

É um cenário muito novo! Refatorando o ditado, eu posso dizer que &quot;a ocasião faz a inovação&quot;. Foi assim com os SGDBs relacionais para os bancos e telecoms e é agora com os bancos não-relacionais para as aplicações Web.

Infelizmente o que deve acontecer em alguns cenários é o radicalismo inverso. Já estou prevendo (rs) profissionais utilizando bancos da &quot;fauna NoSQL&quot; que não suportam ACID em contexto onde estes requisitos devem ser atendidos e o projeto falhar.

Outro problema é que o termo NoSQL é muito infeliz (assim como Agile na minha humilde opinião), uma pena pra tecnologias/conceitos tão bacanas:

NoSQL - Os problemas de um termo infeliz
<!-- m --><a class="postlink" href="http://www.pythonologia.org/2010/03/28/os-problemas-de-um-termo-infeliz/">http://www.pythonologia.org/2010/03/28/ ... o-infeliz/</a><!-- m -->

Mas sabemos que isso é normal no hype cycle de toda nova tecnologia:

Wikipedia: Hype Cycle
<!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/Hype_cycle">http://en.wikipedia.org/wiki/Hype_cycle</a><!-- m -->

Understanding Hype Cycles
<!-- m --><a class="postlink" href="http://www.gartner.com/pages/story.php.id.8795.s.8.jsp">http://www.gartner.com/pages/story.php.id.8795.s.8.jsp</a><!-- m -->

Aproveitando o assunto, em nossa área muitas vezes rola um terrorismo pop do tipo &quot;se você não usa tal ferramenta, você não é um bom profissional&quot;, quando deveria ser &quot;se você conhece as opções e usa a ferramenta mais indicada, você é um bom profissional&quot;. Até mesmo porque não existe ferramenta &quot;certa&quot;, existe ferramenta mais indicada!

Bom, então vamos estudar soluções e ferramentas - ler os artigos do Kico sobre MongoDB é um bom começo! hehehhe

NoSQL na cabeceira da cama, pra saber escolher a solução mais indicada. =)

PS.: Pensando com meus botões sobre soluções NoSQL, como fica o problema de &quot;vendor lock-in&quot;?


0
Trabalho com desenvolvimento, profissionalmente, desde 1.998, e desde este ano trabalho com o Oracle, até por que o Órgão que trabalho é o maior cliente da Oracle no mundo (pelo menos era até tempos atrás). Por quê digo isso, por que tudo na informática tem um porquê e um custo, concordo quando vocês dizem que não dá pra dizer; SGDB é ótimo, assim como concordo que não dá pra dizer: Java é melhor que python, por exemplo. É tudo uma questão de contexto.

90% (estatística de chutrômetro, como 92,35% das estatísticas de fóruns e listas) dos sistemas que são desenvolvidos pelo programador médio pode ser resolvido com uma linguagem de altíssimo nível (Ruby, Python), com um bom framework (Rails, Django), num banco razoável (MySQL, SQLite). O quê vai ser escolhido, isso depende de quem pode escolher.

A escolha de uma linguagem, um framework, um banco de dados, ou mesmo a forma como desenvolver (no banco, na aplicação), normalmente é definida pelas paixões, pelo apego ao conhecimento já adquirido, ou pelo apego à novidade.

Em resumo: concordo com você, só vale a pena utilizar SP quando houver uma necessidade de processamento que justifique sua escolha, não sou tão radical quanto você (que acredita que esta necessidade só é válida pra bilhetamentos), mas é por aí mesmo.

Na minha Opinião, claro.
25/05/2010 00:00


0
Sabe Wanderson,

O problema do vendor lock in com NoSQL é na realidade MUITO pior do que com os SGBDs relacionais. E isto, é engraçado: ninguém comenta.

Não porque vamos estar nas mãos de uma corporação tirânica, mas porque no final das contas, estamos nas mãos de algo qu enão tem padrão definido (também, nem tem muito como ter um padrão) e, ainda pior, nas mãos de grupos muito pequenos.

Migrar de um SGBD relacional pra outro pode ser trabalhoso, mas é possível e muita gente faz isto. Agora, tentar migrar por exemplo de um Neo4J pra um MongoDB pra um Cassandra pra um CouchDB já é beeeeeem mais complicado.

Na realidade, não sei nem se a idéia da migração é válida neste contexto, visto que aqui a gente topa com formatos de dados mais próximos da arquitetura da aplicação né? Ao contrário do modelo relacional, no qual &quot;one size fits all&quot;.

Outro problema que vejo com o NoSQL, e que é mais um medo que um problema é o seguinte: ando vendo muita gente adotando só por adotar ou por status ou por algo completamente desprovido de razão. Acreditem: eu VEJO monstrinhos virando mamutes voadores em chamas em um futuro bem próximo rondando algumas empresas em TI.

E, só pra constar, eu AMO o movimento noSQL, só que quem ama critica né? Na realidade, sempre me incomodou e muito foi o modelo relacional, que tenta enquadrar em um mundo bidimensional algo que é muito mais complexo que, no caso, é a própria realidade (exercício pra vocês: tentem representar uma matriz em um modelo relacional <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> ).


0
Valeu pelo feeback, que adicionou ainda mais embasamento ao assunto!

[quote=&quot;alyssonbruno&quot;]Em resumo: concordo com você, só vale a pena utilizar SP quando houver uma necessidade de processamento que justifique sua escolha, não sou tão radical quanto você (que acredita que esta necessidade só é válida pra bilhetamentos), mas é por aí mesmo.

Na minha Opinião, claro.[/quote]

Sem dúvida. Eu como profissional só vi estes dois cenários - devem ter outros claro - mas somente estes eu posso garantir porque eu trabalhei nestes contextos.

Você passou por algum cenário diferente destes que justificou programar dentro do SGBD?

Infelizmente já vi vários cenários onde se programavam coisas necessárias em Stored Procedures, mas devido a &quot;inércia&quot; (conhecimento, cultura, ambiente...) também se programavam muitas coisas que não eram indicadas para SPs. A manutenibilidade das SPs é algo de arrepiar, ainda mais quando a coisa cresce de tamanho.

Também tenho visto muitos grupos que simplesmente abominam SPs, como se elas não tivessem uso prático. Como se o MySQL 5, a título de exemplo, adicionasse suporte a SPs à toa! hehheheh

Já vi monstros de SPs bonzinhos, mas também já vi monstros cabeludos! =)

O caminho do meio é indicado - aí mora uma boa arquitetura.

Mas só sabe realmente qual o caminho do meio aquele que conhece a variedade entre os extremos - aí moram os estudos e a experiência prática.

Abração!


0
[quote=&quot;kicolobo&quot;]O problema do vendor lock in com NoSQL é na realidade MUITO pior do que com os SGBDs relacionais. E isto, é engraçado: ninguém comenta.[/quote]

Suspeitei deste o princípio... não quis afirmar porque só fiz POCs com duas opções =)

No Hype Cycle esta fase é chamada de &quot;Peek of Inflated Expectations&quot;. É o que estamos vendo.

Dai quando tiver muita app com bancos NoSQL, vai rolar um &quot;Trough of Disillusionment&quot; pesado! Assim como o Agile passou nos dois ultimos anos, com muito projeto utilizando metodologia ágil fracassando por falta de contexto e conhecimento.

Bom, isso é normal. Mas nós devemos ficar atentos pra não entrar em um modelo de avião em construção, que ainda não foi testado amplamente!

[quote=&quot;kicolobo&quot;]E, só pra constar, eu AMO o movimento noSQL, só que quem ama critica né? Na realidade, sempre me incomodou e muito foi o modelo relacional, que tenta enquadrar em um mundo bidimensional algo que é muito mais complexo que, no caso, é a própria realidade (exercício pra vocês: tentem representar uma matriz em um modelo relacional <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> ).[/quote]

Eu também amo qualquer coisa que nos faz pensar fora da caixa! =)


0
[quote=&quot;wanderson.santos&quot;][quote=&quot;kicolobo&quot;]O problema do vendor lock in com NoSQL é na realidade MUITO pior do que com os SGBDs relacionais. E isto, é engraçado: ninguém comenta.[/quote]

Suspeitei deste o princípio... não quis afirmar porque só fiz POCs com duas opções =)

No Hype Cycle esta fase é chamada de &quot;Peek of Inflated Expectations&quot;. É o que estamos vendo.

Dai quando tiver muita app com bancos NoSQL, vai rolar um &quot;Trough of Disillusionment&quot; pesado! Assim como o Agile passou nos dois ultimos anos, com muito projeto utilizando metodologia ágil fracassando por falta de contexto e conhecimento.

Bom, isso é normal. Mas nós devemos ficar atentos pra não entrar em um modelo de avião em construção, que ainda não foi testado amplamente!

[quote=&quot;kicolobo&quot;]E, só pra constar, eu AMO o movimento noSQL, só que quem ama critica né? Na realidade, sempre me incomodou e muito foi o modelo relacional, que tenta enquadrar em um mundo bidimensional algo que é muito mais complexo que, no caso, é a própria realidade (exercício pra vocês: tentem representar uma matriz em um modelo relacional <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> ).[/quote]

Eu também amo qualquer coisa que nos faz pensar fora da caixa! =)[/quote]

Esta mesma desilusão que você mencionou vejo acontecer NESTE momento com Grails e Ruby on Rails. NO caso, nem é por culpa dos frameworks, mas porque criou-se a ilusão de que eles eram &quot;mamão com açucar 100% adocicado com vitaminas naturais&quot; e que fariam tudo de graça para o programador. Como BEM sabemos, não é o caso.


0
[quote=&quot;wanderson.santos&quot;]
Sem dúvida. Eu como profissional só vi estes dois cenários - devem ter outros claro - mas somente estes eu posso garantir porque eu trabalhei nestes contextos.

Você passou por algum cenário diferente destes que justificou programar dentro do SGBD?
[/quote]
Aqui, em nossa empresa, temos um sistema de folha de pagamento que é replicado em todos os Regionais (Um pra cada estado) e os regionais precisavam de alguma autonomia pra trabalhar, então colocou-se a parte do Negocio que os regionais necessitavam de liberdade em SP. Outra grande vantagem é que quando vamos fechar as folhas de pagamento o processamento é bem mais rápido. Não sei se esta é a melhor solução, nem que outras soluções foram pensadas, pois trabalho em um dos Regionais, mas achei bem pertinente esta abordagem.
[quote=&quot;wanderson.santos&quot;]

Infelizmente já vi vários cenários onde se programavam coisas necessárias em Stored Procedures, mas devido a &quot;inércia&quot; (conhecimento, cultura, ambiente...) também se programavam muitas coisas que não eram indicadas para SPs. A manutenibilidade das SPs é algo de arrepiar, ainda mais quando a coisa cresce de tamanho.

Também tenho visto muitos grupos que simplesmente abominam SPs, como se elas não tivessem uso prático. Como se o MySQL 5, a título de exemplo, adicionasse suporte a SPs à toa! hehheheh

Já vi monstros de SPs bonzinhos, mas também já vi monstros cabeludos! =)

O caminho do meio é indicado - aí mora uma boa arquitetura.

Mas só sabe realmente qual o caminho do meio aquele que conhece a variedade entre os extremos - aí moram os estudos e a experiência prática.

Abração![/quote]
O caminho do meio é o caminho do Nibbana, já dizia o Buddha a 4.500 anos atrás.
27/05/2010 00:00



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto