Guarda ali, ó...

[DadoCe]

É isso ai galera, antes de viajar, quero abrir uma discussãozinha aqui aproveitando o gancho do que ta rolando na comunidade.

No dia que fizemos nossa reuniãozinha no Extra, em uma de nossas conversas, um dos brothers abriu um assunto que, como eu disse lá, existem discussões quilométricas sobre ele por ai a fora. Em seguida, comentei, para alguns que estavam por lá, que abriria um post em seguida pra saber a opinião da galera sobre o fato, mas acabei arquivando.

Então. No Halloween, sei lá o que aconteceu com nosso titio Uncle Bob (redundância?), que ele começou escrotizar várias coisas em seus tweets. Foi uma aula muito foda e só lamento aos que não tem uma conta lá, pois não vou transcrevê-los aqui (6).

Pois bem, vamos ao foco. Em um desses tweets do tio, ele falava sobre regra de negócio no banco, usando SQL ou quaisquer variação dela. Em seguida a galera do dot net architects abriu um post sobre isso também que rendeu, e tá rendendo, centenas de mails.

Por fim, eu quero saber da nossa galera aqui: qual é sua posição com relação a manter business rules no banco nos dias de hoje?

Estou indo à RubyConfBr agora, juntamente com meu brother Murillo, e esperamos trazer bastante novidades de lá para nossa comunidade. Agitem ai, galera!

o>

@DadoCe

[Neoromancer]

Não gosto de regras de negócio no banco.
em muitos casos dá muito acesso ao banco e lentidão.
e acho que banco não foi feito pra guardar esse tipo de informação

[Eduardo Rizzi]

Essa é uma questão crítica e não existe uma resposta exata, sempre vai depender do projeto...

Devemos analisar questões como:

- Relação inserções/atualizações X Consultas;

- Linguagem compilada ou interpretada;

- Conexão local ou remota;

- Mudanças futuras no DB, como atualização ou até troca do SGBD;

- Tipos de dados armazenados....

[Diego Souza Rodrigues]

de verdade...
me explica uma forma onde a regra de negócio no banco seja uma escolha a se fazer.
Pq muito provavelmente existe já outras alternativas para não escolher isso..

[William Pinto]

@Diego, Exclusão em cascata é um exemplo onde regra no banco é bem vinda.

[Lauro Caetano]

Pra mim a única coisa boa do banco é armazenar dados.

Também serve a exclusão em cascata, que com algumas linguagens/frameworks ORM não é tarefa das mais elegantes.

--
Lauro Caetano
Bacharel em Ciência da Computação - UFMT
Sun Certified Java Programmer 6

[Eduardo Rizzi]

Em SGBDs relacionais onde existe um número muiiiiiiiito grande de consultas, as vezes é necessário desnormalizar, gerando algumas redundâncias para aumentar a velocidade das consultas, neste caso atualizações são complexas e gatilhos podem reduzir muito o esforço no desenvolvimento do software.

[Valder Zacarkim - Zakim]

Não vejo problemas em armazenar regras no banco, desde que haja um porque válido e uma rigidez bem definida quanto a qualidade disso. (Coisa que não acontece!)

ps: Eu nunca faria isso, embora não veja pq não fazer.. hehehe. É tão mais simples ter tudo isso centrado no código....

2011/11/2 Eduardo Rizzi <ri...@pantanaltec.com.br>

Em SGBDs relacionais onde existe um número muiiiiiiiito grande de consultas, as vezes é necessário desnormalizar, gerando algumas redundâncias para aumentar a velocidade das consultas, neste caso atualizações são complexas e gatilhos podem reduzir muito o esforço no desenvolvimento do software.

--
Valder Zacarkim - Zakim

Twitter -> @_zakim_
Blog -> http://www.ocomeco.com

[leonardo souza de assis]

eu já concordo com o Eduardo quando ele diz que depende do projeto. Mas mesmo assim eu acho que deve-se centralizar a regra e manter a camada da regra de negócio em um só lugar. 

Se vai por no banco, põe tudo no banco. Atualmente a gente vive um drama na empresa onde trabalho justamente porque a regra está dividida em vários lugares, dificultando a manutenção

--
Leonardo Souza de Assis
(65)9643-4155

[Diego Souza Rodrigues]

não enxergo um projeto que essa opção seja escolhida.. se passa algum na cabeça de vocês postem aí @Gnomo e @Eduardo.

acho que exclusão em cascata não seria um forte motivo pra eu escolher por as regras no banco

[Lauro Caetano]

Diego, quando você tem vários registros para apagar acaba sendo muito chato de fazer com código. Aconteceu algo do tipo no meu trabalho. Precisavamos deletar N registros com N filhos e fazer isso com hibernate seria demorado. Sair anulando N referencias, deletando e etc. Por isso essa operação foi feita diretamente no banco. Claro que isso vai da situação e nesse caso a situação era o prazo apertado.

Não consigo enxergar o banco de dados como um local apropriado para regras de negócio. Pra mim, isso é um mau cheiro.

[Dado Rodrigues]

E aí, galera. A discussão tá muito massa mas eu to sentindo um certo desconforto. 

Fui no Wikipédia pedir ajuda, mais uma vez, e trouxe um fragmentozinho pra ajudar na delonga da thread. Lá diz: "Regras do Negócio são declarações sobre a forma da empresa fazer negócio. Elas refletem políticas do negócio. Organizações têm políticas para satisfazer os objetivos do negócio,satisfazer clientes, fazer bom uso dos recursos, e obedecer às leis ou convenções gerais do negócio. Regras do Negócio tornam-se requisitos, ou seja, podem ser implementados em um sistema de software como uma forma de requisitos de software desse sistema. Representam um importante conceito dentro do processo de definição de requisitos para sistemas de informação e devem ser vistas como uma declaração genérica sobre a organização".

Trouxe isso só pra gente dar uma desvinculada da regra de negócio de infra de projeto. 

:)

@DadoCe

Enviado via iPhone

[Thiago Pereira]

Eu vou na idéia do Léo e do Eduardo, depende do projeto...

Conforme o Léo citou, no sistema com o qual trabalhamos a regra está dividida em diversos locais, isso ocorreu por vários motivos, sendo o principal que eu vejo as várias migrações pelo qual o mesmo passou (COBOL > Delphi > Java), sendo que a equipe inicial (COBOL) não pensou nesse assunto, já em Delphi melhoraram um pouco e no Java pelo menos tentamos colocar as regras no BD. Eu vejo a vantagem de se colocar a regra no BD justamente nesses casos de migrações (é muito mais fácil mudar a linguagem) principalmente em um sistema com o qual estávamos trabalhando que já estava há muito tempo implantado nos clientes...

Por esses motivos eu vejo que depende do projeto...

---

De: "Dado Rodrigues" <dad...@gmail.com>
Para: yod...@googlegroups.com
Enviadas: Quinta-feira, 3 de Novembro de 2011 1:16:39
Assunto: Re: [yoDojo] Re: Guarda ali, ó...

[Rodrigo Marcel Vieira Nunes]

Concordo com o Thiago, Léo e do Eduardo.
Depende do projeto. O caso que o Thiago citou é exatamente a minha
realidade atual. Mais de 90% da regra de negócio é centrada no banco.
Acontece que o ambiente é muito hibrido, existem muitos processos de
integração, tem muitas tecnologias diferentes (web), nem tanto
desktop.
Acaba que a aplicação passa a ser apenas uma interface com o usuario.
Ja pensou se tivesse que mudar a regra de negocio, e de repente
tivesse que ser mudada em N aplicações com tecnologias diferentes?


Att,

Rodrigo Marcel

[Lauro Caetano]

MVC?

Você pode escrever um código limpo, coberto por testes e isola-lo em uma camada core, onde vc armazena todas as regras de negócio e etc.

Com isso, vc pode escrever N views para o teu projeto. Web, Desktop, Mobile e etc.

Quando a regra fica no banco você perde todas as vantagens da orientação a objetos, fica extremamente limitado e é difícil de testar.

 

Att,

 Rodrigo Marcel

[William Pinto]

@Lauro, mais é ai qnd eu tenho uma versao da Aplicação em Delphi outra em Java, e outra em php.

[Lauro Caetano]

REST, SOA, whatever

[William Pinto]

whatever nao conheço.

[Luiz Fonseca]

Pra isso servem APIs.

[William Pinto]

Pra mim a Solução e criar algum framework caseiro que facilite a migração e migrar tudo logo pra mesma tecnologia, da pra fazer isso rapidao em 5 ou 6 anos ta pronto.

[Lauro Caetano]

Será que a regra do twitter tá escrita no banco? e do Facebook? Amazon? 

E eles tem app pra iphone, android, windows mobile, symbian, web e se brincar até pra mp3 player..

Em 3 de novembro de 2011 11:39, Luiz Fonseca <runer...@gmail.com> escreveu:

[Rodrigo Marcel Vieira Nunes]

Será que todos os projetos são como o Twitter!?

On 3 nov, 12:44, Lauro Caetano <laurocaeta...@gmail.com> wrote:
> Será que a regra do twitter tá escrita no banco? e do Facebook? Amazon?
>
> E eles tem app pra iphone, android, windows mobile, symbian, web e se
> brincar até pra mp3 player..
>

> Em 3 de novembro de 2011 11:39, Luiz Fonseca <runeron...@gmail.com>escreveu:
>
>
>
> > Pra isso servem APIs.
>
> > On Nov 3, 2011, at 11:29 AM, William Pinto wrote:
>
> > @Lauro, mais é ai qnd eu tenho uma versao da Aplicação em Delphi outra em
> > Java, e outra em php.
>

> > Em 3 de novembro de 2011 11:28, Lauro Caetano <laurocaeta...@gmail.com>escreveu:
>
> >> Em 3 de novembro de 2011 11:11, Rodrigo Marcel Vieira Nunes <

> >> web.rmar...@gmail.com> escreveu:

[William Pinto]

Olha a Regra do Twitter aqui,

 if(text.length >140)
alert(Erro);

E no banco coloca o tamanho da coluna como varchar(140)

pronto, viu o twitter tem a regra nos 2 lugares

[Eduardo Rizzi]

Eu não posso afirmar sobre facebook, amazom e os demais sistemas gigantescos (não sei como implementaram), o fato é que em sistemas web grandes precisamos fazer diversas desnormalizações (gerar redundâncias) para aumentar a velocidade de consulta, e controlar essas redundancias pela aplicação é suicídio, mto mais fácil pelo sgbd.

E por curiosidade, como ter certeza que eles não tem nenhuma regra no banco?

[Lauro Caetano]

Frango, eu não manjo de noSQL então não posso afirmar se com noSQL é possível escrever regras no banco.

[William Pinto]

Qnd o sistema é grande demais, com o banco grande demias, eles usam ferramentas de B.I para fazer as parada, é isso nao tem nada a ver com a regra de negocio.

[Lauro Caetano]

Nem todos os projetos são como twitter. Se for qualquer crud e ninguém for usar...

Essa é minha visão. Se eu fosse escrever um projeto, não colocaria 1 regra no banco.

[Thiago Pereira]

Justamente, "nem todos projetos são como twitter"... Por isso eu não posso dizer que não escreveria nenhuma regra no banco...
Até porque não tem comparação a quantidade de regras de negócio de um twitter, facebook, amazon com um ERP, um Sistema Bancário, entre outros...
O próprio PMBOK define cada projeto como "ÚNICO", cada um tem suas características específicas, impossível dizer que nunca usarei determinado recurso para desenvolver um projeto.

---

De: "Lauro Caetano" <lauroc...@gmail.com>
Para: yod...@googlegroups.com
Enviadas: Quinta-feira, 3 de Novembro de 2011 12:00:14

Assunto: Re: [yoDojo] Re: Guarda ali, ó...

[Bruno Balbinot]

Rolando mt extremismo hein.

"Não coloco NADA no banco."

"Coloco TUDO no banco."

 

Eu penso que devemos aplicar a moderação.

Eu uso bastante regra de negócio no banco, em grandes sistemas é preciso isso pra vc não destruir com sua transferência de dados.

Acho totalmente usual bancos de dados que possuem vários sistemas em diferentes plataformas utilizar as regras comuns dos sistemas no banco de dados. As específicas fica em cada aplicação.

 

Além disso vocês estão esquecendo de empresas que tem sistemas rodando sem parar 24 horas por dia, e que tem regras que mudam a toda semana, muitas você altera a regra no banco e pronto, não precisa desgastar a reputação do seu sistema desconectando 5000 usuários (o que pode vir a acontecer)  numa publicação/nova verão emergencial bem no meio da semana.

 

São casos e casos.

Em 3 de novembro de 2011 12:00, Lauro Caetano <lauroc...@gmail.com> escreveu:

Nem todos os projetos são como twitter. Se for qualquer crud e ninguém for usar...

Essa é minha visão. Se eu fosse escrever um projeto, não colocaria 1 regra no banco.

--
Bruno Balbinot dos Anjos

Desenvolvedor

(65) 9996-0606 - Vivo

(65) 9259-4533 - Claro
Cuiabá - MT

[Thiago Pereira]

Exatamente Bruno, extremismo nunca é bom...

---

De: "Bruno Balbinot" <anj...@hotmail.com>
Para: yod...@googlegroups.com
Enviadas: Quinta-feira, 3 de Novembro de 2011 13:56:51

Assunto: Re: [yoDojo] Re: Guarda ali, ó...

[William Pinto]

São os Extremistas que fazem a mundança no mundo e não o pessoal do "tem que ver".

@Bruno. com Weblogic eu posso subir uma versão nova das regras sem precisar desconectar ninguem, muito melhor que o banco de dados que precisaria no minimo recarregar a conexão

[Lauro Caetano]

Não é por que nem todas as aplicações são como Twitter que elas podem ser escritas de qualquer jeito.

[Glauber Hofman]

É parceiro, essa é uma visão bem extremista das coisas.

---

From: willia...@gmail.com
Date: Thu, 3 Nov 2011 14:11:33 -0300
Subject: Re: [yoDojo] Re: Guarda ali, ó...
To: yod...@googlegroups.com

[Thiago Pereira]

Discordo disso: "São os Extremistas que fazem a mundança no mundo e não o pessoal do 'tem que ver' "... Essa semana extremistas tocaram fogo na sede de uma revista de comédia da França pq publicou uma charge sobre maomé... Não vejo como eles estão "mudando o mundo"....

Pessoas que mudam o mundo são aquelas que tem uma idéia e foco, totalmente diferente de "extremismo"... Duvido que Steve Jobs não precisou analisar diversas tecnologias antes de suas invenções... Ele tinha a idéia na cabeça...

O que estou dizendo não é que temos que usar sempre as regras no banco, mas que eventualmente esse pode ser um recurso que precise e não posso descartá-lo...

---

De: "William Pinto" <willia...@gmail.com>
Para: yod...@googlegroups.com
Enviadas: Quinta-feira, 3 de Novembro de 2011 14:11:33

[Rodrigo Marcel Vieira Nunes]

Esse assunto é mesmo polêmico hein. Poem até terrorismo no meio.
O bacana é que estou conhecendo vários recursos novos.

Att,

Rodrigo Marcel

[Diego Souza Rodrigues]

bom, eu não colocaria meu ventilador de teto na parede de forma alguma

[William Pinto]

Edesde quando o Steve Jobs mudou o mundo? O que fez de bom pra sua vida?? Pra minha nada.

[Guilherme Cardoso]

Pessoal ta desviando o foco da discussão :P

[Glauber Hofman]

Já eu, se estivesse com muito calor e fosse a única opção na qual eu conseguisse pensar e claro, se funcionasse, colocaria.

É como no Fifa 12 que eu coloco o Neymar de ponta esquerda. Claro que a posição ideal pra ele não é aquela, mas eu ganho os jogos com ele lá.

Att.
Glauber Hofman

---

Date: Thu, 3 Nov 2011 14:27:09 -0300

Subject: Re: [yoDojo] Re: Guarda ali, ó...

From: diegos...@gmail.com
To: yod...@googlegroups.com

[William Pinto]

Ventilador de teto na parede foi um pessimo exemplo... Estudei em uma escola q tinha ventilador de teto na parede e funcionava normal.

Vamos Quebrar os paradigmas pessoal!

[Diego Souza Rodrigues]

(Ventilador de teto) na (Parede)

[Robson Cassol]

Mamilos

[William Pinto]

Poha Robson vai se fuder, rolando um discussão seria aqui e vc vem Trollar

[Diego Souza Rodrigues]

a gente tem que ter muito cuidado com esse "se funcionasse"

[Lauro Caetano]

Meu último post nesta thread:

http://escalabilidade.com/2010/03/08/introducao-ao-nosql-parte-i/

Galera que manja mais de banco pode responder como fica a escalabilidade da aplicação quando você tem a maioria das regras no banco? Não entendo dessa parte.

E como que fica a orientação a objetos? Fica tudo procedural? Realmente não conheço essa parte, desculpa pela minha ignorância.

[William Pinto]

@Diego, Experiencia significa Experimentar, se vc nao tentar algo diferente é ver se funciona vc nunca vai evoluir ficar 10 anos fazendo CRUD nao vai te dar experincia nenhuma,
se vc nunco colocou uma regra no banco, pq apredeu que nao deve ser assim que base vc tem para falar q ela não deve ficar ali?

[Bruno Balbinot]

Então. Já que tá pegando fogo vou jogar gasolina e oxigenio.

 

FKs? Pra mim além de integridade é uma regra de negócio.

Para o banco tratar FK é easy, mas pra fazer essa regra/integridade na aplicação, nooooossa, custa uma bola.

Em 3 de novembro de 2011 14:46, Robson Cassol <robson...@gmail.com> escreveu:

[William Pinto]

FK nao é e nunca foi ou vai ser regra de negocio Bruno, nem validação de formularios é regra de negocio

[Valder Zacarkim - Zakim]

hahahaha.... Discussão acalorada...

Penso que o extremismo não é uma coisa boa! E Steve Jobs não era um extremista! E extremistas não são gênios e sim ignorantes por desconhecer o outro lado da história/situação! E todo extremista acredita estar fazendo o bem para alguma coisa (camicase), mesmo que todos pensem o contrário. E competência e atitude não significa extremismo.... e por ai vai...

As soluções estão ai para nos ajudar, mesmo que a contra gosto. Eu não gosto de regra no banco de dados e acho isso uma afronta a tudo que pregamos sobre testes e arquitetura de software. 

É muito mais simples manter e garantir a qualidade um código na aplicação do que no banco, mas eu sei que por questões de performance, as vezes deixar no banco pode ser a melhor opção.

Devemos aprender a viver com isso e buscar sempre a melhor solução para o cliente e não para o nosso ego!

2011/11/3 William Pinto <willia...@gmail.com>

--
Valder Zacarkim - Zakim

Twitter -> @_zakim_
Blog -> http://www.ocomeco.com

[Eduardo Rizzi]

Seguindo a ideía do Lauro achei isso mto interessante

http://imasters.com.br/artigo/17043/bancodedados/nosql_voce_realmente_sabe_do_que_estamos_falando/

"Em um projeto, não necessariamente você precisa usar só um banco de dados Nosql, é possível usá-lo em conjunto com qualquer outro banco de dados. Os bancos Nosql são indicados para grandes cargas de dados, exigência de velocidade na consulta e escrita em grandes volumes de dados.

Ainda segundo o gráfico, 90% dos sites atualmente podem usar sem problemas algum os bancos de dados tradicionais, pois o ganho de performance não seria tão significativo; para os 10% restantes é aconselhável o uso do NoSQL. 

A idéia que o conceito NOSQL nos passa é que ele não pode ser generalizado como a resposta de todos seus problemas, mas sim para problemas específicos. "

TUDO DEPENDE DO PROJETO.

[Rodrigo Marcel Vieira Nunes]

\o

Por mim eu fecharia o tópico com a frase do Valder.

"Devemos aprender a viver com isso e buscar sempre a melhor solução
para o cliente e não para o nosso ego!"

That's all.

[William Pinto]

só os extremistas postaram argumentos até agora, quem está em cima do muro não disse nada além de "tem que ver" e "depende"

[Diego Souza Rodrigues]

O que quero dizer não é experimentar algo novo para novas descoberta, mas usar o "se funcionar" como "se tá funcionando, nem toca".

Onde deve ser instalado um ventilador-de-TETO ?

@Lauro deixou um último post bacana. Valeu broder.

[leonardo souza de assis]

"Depende do projeto" é um argumento.

--
Leonardo Souza de Assis
(65)9643-4155

[William Pinto]

@Rodrigo Eu ACHO que TEM QUE VER, se da pra fechar, TALVEZ da, mais isso DEPENDE Muito

[Rodrigo Marcel Vieira Nunes]

@William Entendo o que você quer dizer. Mas tudo ao extremo
potencializa os riscos, e riscos precisam ser calculados.

att,
Rodrigo Marcel

On 3 nov, 16:08, William Pinto <williamchi...@gmail.com> wrote:
> @Rodrigo Eu ACHO que TEM QUE VER, se da pra fechar, TALVEZ da, mais isso
> DEPENDE Muito
>
> Em 3 de novembro de 2011 15:07, Diego Souza Rodrigues <

> diegosouz...@gmail.com> escreveu:

[William Pinto]

@Rodrigo, eu nao to falando para ninguem ser extremista, eu mesmo uso PK no banco, e em uma situação especial lah ja usei ate uma FK no meu banco, so not null que nunca cheguei ao extremo de usar.

[Valder Zacarkim - Zakim]

Depois que conheci e me tornei fan de bancos nosql, quebrar regra de normalização em banco relacional já não me parece mais uma transgressão grave.

2011/11/3 William Pinto <willia...@gmail.com>

[Altieri Pereira]

Ola para todos.

Hoje minha caixa de emails foi "trolada" com varias mensagens do
Grupo, agora que fui ler entendi o motivo, rs. Regras no banco de
dados é realmente o pavio para discussões acirradas.

Na minha opnião de Me@rdd*# , justificar performance é grande
besteira. Hoje, sabemos que o gargalo esta justamente na transferência
de dados e não no processamento, então isso não é justificativa para
colocar regra de negocio no banco de dados, ja que o sgdb pode até
processar rapidamente, mas nosso sistema precisa obter as informações
de alguma maneira, e nisso uma procedure não ajuda. Agora, eu sou a
favor de procs para rotinas que tem a ver com banco de dados. Extração
de massas de dados por exemplo, eu não vejo motivo para não utilizar
proc's.


;) até mais galera.

On 3 nov, 11:58, Lauro Caetano <laurocaeta...@gmail.com> wrote:
> Frango, eu não manjo de noSQL então não posso afirmar se com noSQL é
> possível escrever regras no banco.

[Bruno Balbinot]

Concordo com Altieri.

Hj processador e memória agente tem pra dar conta, já que esses componentes físicos são os mesmos utilizados nos países em que a tecnologia da informação está mais avançada, mas a estrutura de internet, servidores remotos e talz aqui no Brasil ficam longe, estou falando em sistema Web, não radicalize achando que tô falando que uma rede interna é ruim.

[Dado Rodrigues]

E aí, galera. 

Aproveitando que eu to aqui com a galera da RubyConf, pedi pra um dos caras mais citados aqui do grupo participar dessa thread :)

Então, fica aí com Fábio Akita: http://t.co/30qSK80b

o>

@DadoCe

Enviado via iPhone

[Luiz Fonseca]

Haha, foda! :D

[Marcio Gouvea Silva]

AWESOME!

Marcio Gouvea Silva
Alta Floresta/Barra do Bugres - MT

[Diego Souza Rodrigues]

essa dica pode ser um divisor dessa thread para todos postarmos os resultados da segunda vez?

[William Pinto]

Diego, cara desculpa mais eu nao entendi o que o Fabio Akita fala no video depois de "regra em banco de dados"
qual foi a dica que ele deixou?

[Guilherme Cardoso]

Eu entendi algo como "tem que se pensar duas vezes", mas tá meio ruim mesmo de entender, o audio está cortando

[Luiz Fonseca]

- E aí Akita?

- Pode passar?

- Pode

- Ok, aqui é Fabio Akita da Rubyconf 2011 - fechamento, fica a dica; regra em banco de dados... embutido: pense 2 vezes."

- Valeu!

[William Pinto]

Esse intervalo do Regra em Banco de dados e Pense 2 vezes nao entendi nada.
Vai ser so o dado para explicar mesmo

[Diego Souza Rodrigues]

A dica foi para pensar duas vezes antes de por a regra no banco. Porque, se agir na primeira, é muito provável que irá fazer alguma caca (como por ventilador-de-teto na parede :P ).

[Robson Cassol]

Então a dica quer dizer que se for bem pensado regra no banco "Podeee" hehe

Em 5 de novembro de 2011 14:48, Diego Souza Rodrigues <diegos...@gmail.com> escreveu:

A dica foi para pensar duas vezes antes de por a regra no banco. Porque, se agir na primeira, é muito provável que irá fazer alguma caca (como por ventilador-de-teto na parede :P ).

--
Robson Hermes Cassol

[Rodrigo Marcel Vieira Nunes]

Com todo respeito ao Akita e aos demais fucking masters que aqui
estão.
Entendo que teoricamente, regras de negocio são em nível de aplicação
mesmo.
Mas pelo fato de minha realidade atual trabalhar com um big sistema
com regra cerca de 90% no banco, eu
não consigo ver tantas desvantagens (e vejo muitas vantagens).
Então, independente de quem falar que deve ser aqui ou alí... pra mim,
o que importa é na prática.
E na prática... pra mim... regra no banco funciona. E ainda esta
funcionando...
E não atrapalha o desenvolvimento em equipe, e ainda assim é
organizado.
Este não deveria ser o princípio das coisas?!

[William Pinto]

Rodrigo, vc tocou no ponto principal a Realidade, na sua realidade isso faz sentido.

[Diego Souza Rodrigues]

galera com maior conhecimento em SQL provavelmente vai optar por colocar toda a regra no banco, como os engenheiros de software tendem a colocar essas regras dentro do aplicativo e aplicar a arquitetura apropriada, design patterns, frameworks  e organizá-los.

Galera do regras-no-banco pode argumentar que podemos fazer “alterações instantâneas " sem recompilar o código e gerar novas versões, e os desenvolvedores regras-no-código podem argumentar que PL/SQL, TSQL,etc são línguagens tão limitadas para depurar e expressar regras de negócio complexas que podem ser muito melhor avaliadas no código, aí é quando Tb concordo com o Lauro quando disse que qnd a regra fica no banco perdemos todas as vantagens da orientação a objetos.

Acredito que escolhendo um design e um arquitetura correta para o projeto essas regras de negócio devem ficar dentro do aplicativo... E pra que o banco de dados? Obtenção de dados e alguma lógica, mas o cérebro de resolver o problema de negócio para mim não vai ser dentro de um procedimento armazenado.

Acho que se por essa discussão em um fórum de SQL e ver qual a resposta deles provavelmente será "põe tudo em procedimentos armazenados!" rs

[Valder Zacarkim - Zakim]

Nosso conhecimento de Engenharia ou sobre Banco de dados é secundário na contagem de pontos para a escolha da solução. Devemos levantar  pontos concretos sobre pq usar cada abordagem.

2011/11/5 Diego Souza Rodrigues <diegos...@gmail.com>

[DadoCe]

E ai, galera.

Fiquei meio ausente nesse últimos dias, mas, já estou de volta.

Como eu tinha dito, estava no RubyConf e um dos caramaradas que estava lá conosco era o Evan Henshaw (ou Rabble). Pra quem ainda não conhece, ele foi o cara que idealizou o ODEO, a startup de onde, tempos depois, acabou originando o Twttr e, em seguida, o Twitter.

Mas enfim, ele contou toda historinha da parada, mas isso não vem ao caso nessa thread. O lance é que, já que o Twitter foi citado aqui, aproveito pra dizer que eles começaram com MySQL como SGDB, mas, foi migrado, tempos depois, para o Cassandra, que é um projeto noSql que começou no Facebook e agora é mantido pela Apache.

Com isso, temos certeza: eles não usam regras no banco.

Agora vou mimi que estou mega quebrado.

=)

@DadoCe

[DadoCe]

Fala galera!

Bem no início do grupo, abri um post chamado "Nos Ombros dos Gigantes" (http://bit.ly/rRnRk3), falando um pouco do que eu achava sobre dar atenção à fala dos "gigantes".

Pois bem, isso não deve ser entendido como "tomar como verdade tudo o que dizem", muito pelo contrário, sempre relutei com relação a isso. O lance é que o que essa galera que eu admiro diz, chega a mim com bastante consideração, ou seja, direciono meu foco em cima do que foi dito pra começar fazer meus testes e considerações. Em outras palavras, pego a verdade desses caras e tomo como minha hipótese (pronto, ficou legal). Mas isso é o que eu faça, jamais diria que isso é o que deve ser feito.

Mas tudo bem, vamos ao que interessa. No RubyConf, como eu vi que essa thread tava massa, tive a idéia de aproveitar momento no meio de uma galera foda e pegar a opinião deles sobre o tema. Conversando com o Akita tive a idéia de fazer videozinhos bem rápidos com uma frase deles sobre o tema e intitulei isso de "140Caracteres".

Infelizmente, não deu tempo fazer com a galera toda que eu queria e acabou rolando vídeo só com o Akita mesmo.

Mas, não paramos por ai. Mesmo sem vídeo, a galera quis contribuir com o yoDojo e mandaram frases para agregar à discussão.

Então segue ai:

TEMA: Regra de negócio em banco de dados

Henrique Bastos

"Como regra geral não cheira bem. Mas se vc PRECISA realmente fazer algo assim, evite PL e use uma linguagem mais expressiva.
E se vc PRECISA disso e seu banco cabe em um HD que vc compra na esquina, deve ser problema de arquitetura e design."

Dougla Campos (QMX)

"o nome é banco de dados, não banco de regras de negócio :P
E o mesmo se aplica pras stored procedures modernas (aka map-reduce jobs) - tem que usar com cautela :)"

Victor Hugo Germano

"Regra de negocio no banco? credo!!! Melhor matar a mae!"

Giovanni Bassi

"Stoned procedure?"

Fábio Akita

"Regra em banco de dados... embutido: pense 2 vezes. Fica a dica!"

Nem preciso falar que é uma honra ter essa galera participando conosco, né!?

Espero podermos fazer mais disso em outros eventos :D

o>

@DadoCe

[Valder Zacarkim - Zakim]

Essa foi a melhor

E se vc PRECISA disso e seu banco cabe em um HD que vc compra na esquina, deve ser problema de arquitetura e design."

2011/11/8 DadoCe <dad...@gmail.com>

[DadoCe]

Continuando com as falas dos brothers:

Luca Bastos

"Minha resposta:

1) Não vejo nenhum mal uma ou outra coisa ser colocada como stored procedure. Para mim os melhores candidatos a isto são algoritmos secretos. Se é para ser secreto, melhor que sejam realmente uma caixa preta (com interfaces bem claras)

2) O que tenho contra Stored procedures é a dificuldade de testar (coloque 5 bandeiras vermelhas aqui) e o fato de rodar no servidor. Hoje redes são rápidas e baratas. Não há mais aquela justificativa de performance de stored procedures.

3) Xingar o uso de stored procedures em casos excepcionais só porque seu ORM favorito apanha delas não tem justificativa.

4) Regras de negócio no banco nem sempre significam uso de stored procedures. Uma tabela com desconto de cada cliente é uma regra de negócio. Onde será que estes "puristas" armazenam isto?

5) Não vejo porque discutir isto de forma genérica. Cada caso é um caso. Se na nossa área as decisões fossem assim passíveis de serem catalogadas, bastava consultar o tal catálogo ao invés de contratar alguém experiente."

=**

@DadoCe

[Murillo M. R.]

Caraka..
140Caracteres bombando com caras altamente phoda!!

Eu achei legal a mistura porque cada um vem de uma comunidade diferente..

Poxa essa ultima do Luca foi muito boa.

Parabéns pela idéia brotha..

Eu quero soh ver quando isso ficar público xD

vlw

[Guilherme Cardoso]

Também to curtindo :D

[Guilherme Cardoso]

bump!

http://tableless.com.br/alergia-sql/

Em quarta-feira, 2 de novembro de 2011 18:11:32 UTC-2, DadoCe escreveu:

É isso ai galera, antes de viajar, quero abrir uma discussãozinha aqui aproveitando o gancho do que ta rolando na comunidade.

No dia que fizemos nossa reuniãozinha no Extra, em uma de nossas conversas, um dos brothers abriu um assunto que, como eu disse lá, existem discussões quilométricas sobre ele por ai a fora. Em seguida, comentei, para alguns que estavam por lá, que abriria um post em seguida pra saber a opinião da galera sobre o fato, mas acabei arquivando.

Então. No Halloween, sei lá o que aconteceu com nosso titio Uncle Bob (redundância?), que ele começou escrotizar várias coisas em seus tweets. Foi uma aula muito foda e só lamento aos que não tem uma conta lá, pois não vou transcrevê-los aqui (6).

Pois bem, vamos ao foco. Em um desses tweets do tio, ele falava sobre regra de negócio no banco, usando SQL ou quaisquer variação dela. Em seguida a galera do dot net architects abriu um post sobre isso também que rendeu, e tá rendendo, centenas de mails.

Por fim, eu quero saber da nossa galera aqui: qual é sua posição com relação a manter business rules no banco nos dias de hoje?

Estou indo à RubyConfBr agora, juntamente com meu brother Murillo, e esperamos trazer bastante novidades de lá para nossa comunidade. Agitem ai, galera!

o>

@DadoCe

[Gabriel Pedro]

​post interessante! as vezes o ORM não consegue supri a necessidade de uma forma simples e acaba-se usando SQL feito na mão mesmo. Mas também existem ODM (object-document mapper) que é uma coisa bem interessante quando se vai trabalhar com nosql e etc... vide Morphia.

Atenciosamente,
Gabriel Pedro.

gpedro.net

--
Você recebeu essa mensagem porque está inscrito no grupo "YoDojo" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para yodojo+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[DadoCe]

Por algum motivo, esse tema sempre me remete às discussões "documentar ou não documentar?"

E assim como no tema documentação (e em quase todos os outros), na minha opinião fecal, deve ser discutido sempre pontualmente analisando o valor retornado.

Quando estávamos no auge dessa thread, o Luca Bastos fez questão de pontuar sua opinião. Nada mais justo que relembra-la. Segue:

[Lauro Ojeda]

Thread interessante, principalmente por eu estar trabalhando exatamente numa situação relacionada e com pontos interessantes que podem gerar algum burburinho aqui.

Estou trabalhando numa empresa com aplicações web para prefeituras e câmaras municipais geradas anteriormente em Java e agora sendo convertido para Genexus. O banco de dados é PostgreSQL (era MySQL). O banco deles cresceu assustadoramente nos últimos meses devido à novos contratos e foi necessário a contratação de um especialista pra voltar a performance para o eixo (tava tudo ficando lento).

Quando as aplicações eram todas em Java, eles utilizavam HQL para acesso aos dados no MySQL (mas não usavam variáveis bind). Nessa época, a aplicação era lenta, demorada pra desenvolver e o hardware precisava ter memória gigante pra funcionar. Mudaram pra GX com banco Postgesql (com uso de variáveis bind) e as melhorias em performance da aplicação ficou bem melhor e a produtividade de desenvolvimento aumentou bastante.

Nos 2 casos a lógica fica toda na aplicação.

Mas como disse, cresceu e deu problemas de performance e espaço. Trabalhando em cima do banco (tuning mesmo), processamentos que antes demoravam 40 minutos caíram pra 3min e queries que rodavam em 12 segundos agora são retornadas instantaneamente. 

Mas qual a mágica?

1) Monitoramento e tuning do banco.

2) Análise e sugestão de mudanças nas queries e no processamento. Ex: um processamento de folha específico que tomava 2-3 horas caiu pra 11 minutos, pq o desenvolvedor pegava os mesmos dados de cada funcionário e atualizava essas infos dentro de um loop. A sugestão foi pegar os dados 1x só, processá-los na aplicação e devolver o resultado 1 única vez. Se colocar esse processamento específico em uma stored procedure, é certo que o tempo de processamento vai cair drasticamente (provavelmente pra menos de 1 minuto), mas será que vale todo o trabalho de conversão? Fica a pergunta...

Resultados finais: ontem tirei um relatório de performance (PG Badger pra quem conhece) onde processamos na semana passada 43,153,327 queries sendo que o pico foi 4,809 queries/seg, performance muito boa na minha opinião.

Moral da história, você desenvolvedor pode estar com a melhor ferramenta do mundo pra desenvolver, usando o servidor mais parrudo que for, mas se não escrever sua aplicação da maneira correta, não tem banco que aguente o tranco quando a aplicação crescer muito. Então seja HQL, ORM, ou query escrita na unha, saiba utilizar as ferramentas da maneira correta, senão vai dar pau lá na frente.

OBS1: Ah, e antes que atirem pedras, estou impressionado com a qualidade das queries escritas automaticamente pelo GX. Na maioria das vezes, as queries são muito bem elaboradas...

OBS2: Meu mundo sempre foi muito Oracle e um pouco de MySQL. Comecei a mexer de fato com Postgresql agora. Posso dizer com bastante clareza: não tenham medo de adotar esse banco pra aplicações profissionais. Ele aguenta o tranco!

Att.,

Lauro Ojeda

--

Lauro Ojeda
Msc. Empreendedorismo e Inovação

Fone: +55 65 9921-1026

[Lauro Caetano]

[Lauro Caetano]

Eu escuto quase que diariamente: "Não escreva este SQL na mão, use os helpers do ActiveRecord".. 

Imagino que muita gente deve ouvir a mesma coisa..

Isso seria um bom tópico pra um bate papo igual tivemos em 2011.