Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Bom dia a todos! Pessoal, atualmente sou desenvolvedor, mas ja tive experiencias com PL\SQl com oracle entre outras e foram bem boas, principal ponto forte foi performance, porém percebi alguns pontos que me levaram a crer que podemos dividir as responsabilidades e deixar de pensar que a regra

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

On 15-01-2016 22:21, iannsp wrote: Implementado no SGDB ou fora dele o custo é dado pela resistencia a mudanças que a arquitetura utilizada define. Pode explicar melhor este conceito? Ficou muito vago. No caso do sgdb, principalmente o postgresql que suporta tipagem dos parametros, sobrecarga

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

On 1/18/16 10:10 AM, Flávio Alves Granato wrote: > On 15-01-2016 22:21, iannsp wrote: >> Implementado no SGDB ou fora dele o custo é dado pela resistencia a >> mudanças que a arquitetura utilizada define. > Pode explicar melhor este conceito? Ficou muito vago. O que manda na capacidade de um

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 22:21, iannsp escreveu: > > > On 1/15/16 3:14 PM, Flávio Alves Granato wrote: > > On 15-01-2016 14:19, iannsp wrote: > >> Eu não consigo enxergar beneficios em ser "multi database" a não ser > >> aumentar as possiblidades de venda, salvo casos em que

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Le 16 janvier 2016 11:16:28 GMT-02:00, Rafael Fialho a écrit : >Em 15 de janeiro de 2016 22:21, iannsp escreveu: >> >> On 1/15/16 3:14 PM, Flávio Alves Granato wrote: >> > On 15-01-2016 14:19, iannsp wrote: >> >> Eu não consigo enxergar beneficios em ser

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 16 de janeiro de 2016 11:45, Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org> escreveu: > Le 16 janvier 2016 11:16:28 GMT-02:00, Rafael Fialho < > rafafial...@gmail.com> a écrit : > >Em 15 de janeiro de 2016 22:21, iannsp escreveu: > >> > >> On 1/15/16 3:14 PM,

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é > quase unanimidade entre desenvolvedores a contrariedade em deixar as regras > de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito. > Acredito que devemos ter bom senso, nem tudo deve ser implementado no

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

2016-01-15 9:04 GMT-02:00 Lucas Viecelli : > > Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é >> quase unanimidade entre desenvolvedores a contrariedade em deixar as regras >> de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito. >>

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Com bons desenvolvedores, o bom senso prevaleceria em decidir o que colocar no banco ou na aplicação. O problema é: esses bons desenvolvedores são muito raros, principalmente por que a grande maioria só entende de um lado (programação) ___ pgbr-geral

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Eu tento definir esse problema com a seguinte frase "quanto maior a distancia entre o dado e a regra de negócio maior a possibilidade de interferencia e consequente falha". Admito que no passado me empolguei tanto com o desenvolvimento utilizando stored procedures que acabei fazendo experiencias

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 12:05, Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org> escreveu: > Le 14 janvier 2016 18:25:05 GMT-02:00, Saraiva Silva < > matheus.sara...@gmail.com> a écrit : > >Isso é um assunto recorrente no meio da comunidade de desenvolvimento, > >e é > >quase unanimidade

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Concordo plenamente. Enviado do meu Telefone LG -- Mensagem original--De: Luiz Carlos L. Nogueira Jr.Data: sex, 15 de jan de 2016 12:07 PMPara: Comunidade PostgreSQL Brasileira;Assunto:Re: [pgbr-geral] Regras de negocio no banco ou na aplicação Com bons desenvolvedores, o

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

; *Para: *Comunidade PostgreSQL Brasileira; > > *Assunto:*Re: [pgbr-geral] Regras de negocio no banco ou na aplicação > > > Com bons desenvolvedores, o bom senso prevaleceria em decidir o que > colocar no banco ou na aplicação. > O problema é: esses bons desenvolvedores são muito ra

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

> > > Seria neste momento que, analisando a proposta, complexidade e > característica de cada projeto, se decida aonde as regras de negócio > estarão e o porquê. Eu diria que também nesta fase se ganha muito > discutindo com seriedade toda a tecnologia envolvida, se ela se adequa a > necessidade

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

On 15-01-2016 14:19, iannsp wrote: Eu não consigo enxergar beneficios em ser "multi database" a não ser aumentar as possiblidades de venda, salvo casos em que esse é o papel do software (orquestrar varias sgdb engines) Não quer dizer que não exista. O paradoxo esta em que, ao tentar se livrar

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 12:50, Rafael Fialho escreveu: > Em 15 de janeiro de 2016 13:38, Leandro Guimarães Faria Corcete DUTRA < > l...@dutras.org> escreveu: > >> Le 15 janvier 2016 13:02:22 GMT-02:00, iannsp a écrit >> : >> >Eu tento definir esse

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

2016-01-15 13:50 GMT-02:00 Rafael Fialho : > > Aproveitando o gancho, creio que a pergunta seria produtiva pra todos. > Como vocês costumam rebater um FDI sobre manter a regra no banco quando > vêm argumentos como: "E se trocarmos de banco?", "E se cliente X quiser que > o

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

On 1/15/16 1:50 PM, Rafael Fialho wrote: > Em 15 de janeiro de 2016 13:38, Leandro Guimarães Faria Corcete DUTRA > > escreveu: > > Le 15 janvier 2016 13:02:22 GMT-02:00, iannsp > a écrit : > >Eu

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Le 15 janvier 2016 13:02:22 GMT-02:00, iannsp a écrit : >Eu tento definir esse problema com a seguinte frase "quanto maior a >distancia entre o dado e a regra de negócio maior a possibilidade de >interferencia e consequente falha". Gostei do sumário. --

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 13:38, Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org> escreveu: > Le 15 janvier 2016 13:02:22 GMT-02:00, iannsp a écrit : > >Eu tento definir esse problema com a seguinte frase "quanto maior a > >distancia entre o dado e a regra de negócio

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 14 de janeiro de 2016 18:25, Saraiva Silva escreveu: > Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é > quase unanimidade entre desenvolvedores a contrariedade em deixar as regras > de negocio no banco. Mas eu nunca vi a opinião de DBAs a

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

> On 15-01-2016 14:19, iannsp wrote: > >> Eu não consigo enxergar beneficios em ser "multi database" a não ser >> aumentar as possiblidades de venda, salvo casos em que esse é o papel do >> software (orquestrar varias sgdb engines) >> > Não quer dizer que não exista. > >> O paradoxo esta em que,

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Boa parte defende o bom sendo e a distribuição de tarefas entre aplicação e o banco. O grande desafio é fazer isso usando frameworks ORMs, pois eles partem da ideia que o banco deve ser um mero repositório, nem se quer são capazes de manipular todos os tipos de dados que os SGDBs permitem. Eu

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 19:49, Saraiva Silva escreveu: > > >> Acho o seguinte se o banco de dados tem todos esses recursos devemos >> explorar o máximo agora para servir só de repositório os NoSQL estão ai pra >> isso. >> > Isso não é verdade. Você pode usar o melhor

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

"""Já vi aplicações com Hibernate usando views, functions, gatilhos, etc. Só saber passar por fora do ORM na hora certa.""" Para isso o programador tem que escrever sqls na aplicação certo? Isso pra mim quebra a vantagem do ORM, pois sua proposta é não deixar que isso aconteça. Se eu tiver que

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 20:21, Saraiva Silva escreveu: > """Já vi aplicações com Hibernate usando views, functions, gatilhos, etc. > Só saber passar por fora do ORM na hora certa.""" > > > Para isso o programador tem que escrever sqls na aplicação certo? Isso pra >

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> Assunto: Re: [pgbr-geral] Regras de negocio no banco ou na aplicação Em 15 de janeiro de 2016 20:21, Saraiva Silva <matheus.sara...@gmail.com> escreveu: """Já vi aplicações com Hibernate usando

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 15 de janeiro de 2016 20:57, Matheus Silva escreveu: > Dependendo do CRUD, SPs podem ser melhor que ORM, podem ter melhor > performance e melhor segurança de integridade e é a esses casos que me > refiro. > É óbvio que ninguém usa ORM pensando em segurança ou

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

On 1/15/16 3:14 PM, Flávio Alves Granato wrote: > On 15-01-2016 14:19, iannsp wrote: >> Eu não consigo enxergar beneficios em ser "multi database" a não ser >> aumentar as possiblidades de venda, salvo casos em que esse é o papel do >> software (orquestrar varias sgdb engines) > Não quer dizer

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

2016-01-14 19:11 GMT-02:00 Fábio Telles Rodriguez : > Acho que tenho hoje praticamente a mesma opinião de 10 anos atrás quando > escrevi isso: > > http://savepoint.blog.br/inteligncia-em-bancos-de-dados/ > > Vejam se concordam. > Eu concordo. Rafael

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 14/01/2016 18:25, "Saraiva Silva" escreveu: > > Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é quase unanimidade entre desenvolvedores a contrariedade em deixar as regras de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito. >

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 14 de janeiro de 2016 18:25, Saraiva Silva escreveu: > Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é > quase unanimidade entre desenvolvedores a contrariedade em deixar as regras > de negocio no banco. Mas eu nunca vi a opinião de DBAs a

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Em 14/01/2016 19:12, "Fábio Telles Rodriguez" escreveu: > > > > Em 14 de janeiro de 2016 18:25, Saraiva Silva escreveu: >> >> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é quase unanimidade entre desenvolvedores a

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Saraiva, Na minha opinião esta justificativa vem da velha máxima de deixar a aplicação independente do banco de dados, assim o BD seria apenas um "repositório de dados" e a inteligencia ficaria toda na camada de aplicação. Ao meu ver isto funciona com bancos de dados corporativos aonde o

[pgbr-geral] Regras de negocio no banco ou na aplicação

Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é quase unanimidade entre desenvolvedores a contrariedade em deixar as regras de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito. ___ pgbr-geral mailing list

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

Talvez porque a definição do modelo de desenvolvimento acabe ficando na mão do time de desenvolvimento mesmo. Mas funciona muito bem com as regras no banco. Também funciona bem na aplicação. -- Rafael Bernard Rodrigues Araújo about.me/rafaelbernard 2016-01-14 18:25 GMT-02:00 Saraiva Silva

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

2016-01-14 18:43 GMT-02:00 Rogerio Carvalho : > > Outro fato que impede a ida de regras de negócio para o banco reside > na falta de preparo dos desenvolvedores em conhecer melhor as linguagens de > manipulação de dados e deixar para os softwares especialistas a >