Re: [pgbr-geral] Trigger Simples

[Euler Taveira]

On 18-01-2016 11:26, Mario Moreira wrote:
> Como sair da lista?
> 
Acesse o link no rodapé deste email.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Trigger Simples

[Euler Taveira]

On 15-01-2016 18:58, Pablo Farias wrote:
> Para inclusao de registro  ficou perfeito mais e para quando ouver
> alteração, no registro preciso atualizar o campo data_atualizacao.
> 
> Com a opção default nao deu certo
> 
Não há necessidade de gatilho para INSERT ou UPDATE se você utilizar o
termo DEFAULT no lugar do valor. Veja:

foo=# create table teste (a integer, b text default 'teste', c timestamp
with time zone default current_timestamp);
CREATE TABLE
foo=# insert into teste (a) VALUES(123);
INSERT 0 1
foo=# select a, b, c from teste;
  a  |   b   |   c
-+---+---
 123 | teste | 2016-01-18 11:16:49.591478-03
(1 registro)

foo=# insert into teste (a, b) VALUES(456, 'foo');
INSERT 0 1
foo=# select a, b, c from teste;
  a  |   b   |   c
-+---+---
 123 | teste | 2016-01-18 11:16:49.591478-03
 456 | foo   | 2016-01-18 11:17:36.760013-03
(2 registros)

foo=# update teste set b = DEFAULT where a = 456;
UPDATE 1
foo=# select a, b, c from teste;
  a  |   b   |   c
-+---+---
 123 | teste | 2016-01-18 11:16:49.591478-03
 456 | teste | 2016-01-18 11:17:36.760013-03
(2 registros)

foo=# insert into teste (a, b, c) values(789, 'bar', DEFAULT);
INSERT 0 1
foo=# select a, b, c from teste;
  a  |   b   |   c
-+---+---
 123 | teste | 2016-01-18 11:16:49.591478-03
 456 | teste | 2016-01-18 11:17:36.760013-03
 789 | bar   | 2016-01-18 11:21:09.560375-03
(3 registros)


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Trigger Simples

[Mario Moreira]

Como sair da lista?
Em 18/01/2016 12:24, "Euler Taveira"  escreveu:

> On 15-01-2016 18:58, Pablo Farias wrote:
> > Para inclusao de registro  ficou perfeito mais e para quando ouver
> > alteração, no registro preciso atualizar o campo data_atualizacao.
> >
> > Com a opção default nao deu certo
> >
> Não há necessidade de gatilho para INSERT ou UPDATE se você utilizar o
> termo DEFAULT no lugar do valor. Veja:
>
> foo=# create table teste (a integer, b text default 'teste', c timestamp
> with time zone default current_timestamp);
> CREATE TABLE
> foo=# insert into teste (a) VALUES(123);
> INSERT 0 1
> foo=# select a, b, c from teste;
>   a  |   b   |   c
> -+---+---
>  123 | teste | 2016-01-18 11:16:49.591478-03
> (1 registro)
>
> foo=# insert into teste (a, b) VALUES(456, 'foo');
> INSERT 0 1
> foo=# select a, b, c from teste;
>   a  |   b   |   c
> -+---+---
>  123 | teste | 2016-01-18 11:16:49.591478-03
>  456 | foo   | 2016-01-18 11:17:36.760013-03
> (2 registros)
>
> foo=# update teste set b = DEFAULT where a = 456;
> UPDATE 1
> foo=# select a, b, c from teste;
>   a  |   b   |   c
> -+---+---
>  123 | teste | 2016-01-18 11:16:49.591478-03
>  456 | teste | 2016-01-18 11:17:36.760013-03
> (2 registros)
>
> foo=# insert into teste (a, b, c) values(789, 'bar', DEFAULT);
> INSERT 0 1
> foo=# select a, b, c from teste;
>   a  |   b   |   c
> -+---+---
>  123 | teste | 2016-01-18 11:16:49.591478-03
>  456 | teste | 2016-01-18 11:17:36.760013-03
>  789 | bar   | 2016-01-18 11:21:09.560375-03
> (3 registros)
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Schema ou Database distintas?

[Rafael Bernard Rodrigues Araujo]

Olá, Felipe.

2016-01-18 10:01 GMT-02:00 Felipe Moura :

>
> Pessoal, estamos passando por um situação onde a equipe de banco de dados
> afirma que trabalhar com esquema no postgres é inseguro e a solução dada
> seria utilizar uma database para cada sistema.
>


Qual é a insegurança apresentada?
Sem informações adicionais, eu diria que a segurança (ou falta de) é a
mesma usando esquemas ou bancos separados. A segurança de acesso no banco é
a partir da autorização de acesso de cada usuário.


>
> Alguém já passou por algo parecido?
>


Sim. Minha separação entre bancos e esquemas é decidido pela estrutura da
aplicação, pois em relação a segurança, temos a mesma.

abraço,
rafael
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

[Felipe Moura]

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 deve ficar so
em um lado.

O ponto que me deixou menos favoravel a deixar regras em banco foram as
repetições de código, visto que quando à uma mudança de regra fica mais
complicado dar manuteção e mudanças são muito comuns ao se desenvolver um
software, outro ponto foi a questão de que toda requisição necessáriamente
chega ao banco de dados e dependendo do numero de requisições isso pode se
tornar um gargalo.

Onde trabalho atualmente utilizamos Postgres + SQLSERVER + Mongo, imagina
deixar a regra em banco, como seria? Nem consigo imaginar uma solução para
reaproveitar a regra em vários bancos sem aumentar a duplicação de código e
consequentemente dificultar a manutenção.

Utilizamos ORM e funciona muito bem, não apenas para cruds. Não vejo
problema algum utilizar uma ORM aproveitando seus pontos fortes e o que ela
não atender fazer uma SP, Function, PL, etc. No final estamos todos
querendo fazer um bom sistema e tudo que for utilizado para alcançar um bom
resultado me parece válido.


Em 18 de janeiro de 2016 10:36, iannsp  escreveu:

>
>
> 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 software em ser alterado no ritmo que a
> equipe de negócios precisa mudar é o quanto a arquitetura é capaz de
> suportar mudanças nesses pontos.
> Uma arquitetura desenvolvida por alguém que desconhece uma área de
> negócios normalmente falha em suportar esses hubs de mudança e ai surge
> o cenário em que o desenvolvedor luta com o software legado para
> encaixar as mudanças. Isso é oq ue chamo taxa de resistencia a mudança
> em uma arquitetura de software.
>
> >
> >> No caso do sgdb, principalmente o postgresql que suporta tipagem dos
> >> parametros, sobrecarga de metodos, multiplas linguagens de programação e
> >> níveis de segurança(acesso ao O.S.) creio que a resistencia da
> >> arquitetura é baixa portanto que desenvolvido por um profissional que
> >> saiba o que é arquitetura de software, entenda do nicho em que o
> >> software que esta escrevendo esta inserindo e pratique simplicidade sem
> >> simplismo.
> > "Creio", "simplicidade" e "simplismo" são palavras que levam a um
> > entendimento muito subjetivo e apoiado na experiência pessoal de cada
> > um. Entender de nicho não deve ser levado em consideração, mas como um
> > adicional pois se contrato um desenvolvedor/DBA eu espero que ele faça
> > muito bem é sistemas e que as regras de nicho fiquem muito bem entendida
> > pelo negócio, aliás é um dos princípios do SOA ( já falaram por ae que
> > SOA não é sistema nem procotolo? ).
> Pois bem, com todo o respeito: discordo completamente.
>  Levar o profissional técnico conhecer de técnica sem conhecer o
> contexto é contra o que acredito.
>  DDD e lean, conceitos que uso no desenvolvimento de sistemas, se
> referem a isso.
>  Sim, as palavras creio, simplicidade e simplismo são de aplicação
> pessoal, mas não são de meu uso exclusivo e tampouco são subjetivas.
>
> >
> > No fundo não respondeu à minha pergunta.
> entendo.
> >> Uma lista em ptbr sobre o melhor e mais fodastico banco de dados open
> >> source do mundo.
> > Concordo contigo, uso ele há mais de 15 anos, mais firme em minha
> > memória tenho a versão 7.3 que não me lembro quando foi lançada.
> puxa.
> >> E SÓ VOCE é 110% do tempo desenvolvedor, eu mesmo sou 99% desenvolvedor,
> >> mas com aquele 1%...
> > não entendi. As vezes tenho dificuldades para entender o sacarmos.
> entendo.
> >> Testes de aceitação são a exposição de um problema. Pense lean.
> > Pensar "lean" seria desenvolver sem testes e principalmente sem permitir
> > aos donos do negócio ter controle sobre as regras e não deveríamos expor
> > este problema? Como você responde subjetivamente, me permite endenter
> > subjetivamente.
> >>
> >> O melhor software que você já escreveu para um cliente é aquele que você
> >> não precisou escrever pq entendeu o problema e resolveu sem uma linha de
> >> código.
> > Não entendi, se na primeira resposta você me diz que o arquiteto tem que
> > entender do nicho para poder ser um bom profissional. Estranho virou um
> > paradoxo.
> é necessario entender de negócio para resolver um problema sem programar.
>
> >> Se você quer resolver o problema do seu cliente você deveria repensar o
> >> seu 110%.
> > talvez.
> >> "quem trabalha com banco de dados" soou preconceituoso.
> > Como se os teus 110% não tivesse sido. Mera formalidade de uma discussão
> > acalorada não leve a mal.
> >> "Empresas grandes 

Re: [pgbr-geral] Schema ou Database distintas?

[Felipe Moura]

Fala Pessoal,

Acredito que minha linha de pensamento segue bem no que vcs postaram aqui.

@rafael, não me explicaram o que seria esta "insegurança", achei bem
estranho essa afirmação e concordo plenamente que a segurança entre ambos é
de certa forma a mesma, dependendo muito das regras de grupos e perfis
definidas por usuário.

Em 18 de janeiro de 2016 11:12, Rafael Bernard Rodrigues Araujo <
rafael.ara...@endel.com.br> escreveu:

> Olá, Felipe.
>
> 2016-01-18 10:01 GMT-02:00 Felipe Moura :
>
>>
>> Pessoal, estamos passando por um situação onde a equipe de banco de dados
>> afirma que trabalhar com esquema no postgres é inseguro e a solução dada
>> seria utilizar uma database para cada sistema.
>>
>
>
> Qual é a insegurança apresentada?
> Sem informações adicionais, eu diria que a segurança (ou falta de) é a
> mesma usando esquemas ou bancos separados. A segurança de acesso no banco é
> a partir da autorização de acesso de cada usuário.
>
>
>>
>> Alguém já passou por algo parecido?
>>
>
>
> Sim. Minha separação entre bancos e esquemas é decidido pela estrutura da
> aplicação, pois em relação a segurança, temos a mesma.
>
> abraço,
> rafael
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 

Atenciosamente,

Felipe Moura
Desenvolvedor
http://about.me/felipewebdf
twitter: @felipewebdf
talk: felipegu...@gmail.com

(61) 8490-8156


*Não é da benevolência do padeiro, do açougueiro ou do cervejeiro que eu
espero que saia o meu jantar, mas sim do empenho deles em promover seu
"auto-interesse".*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] prepared statements

[Euler Taveira]

On 14-01-2016 18:37, Alessandro Lima wrote:
> Pelo que entendi uma das vantagens de usar prepared statements é que o
> parse é realizado apenas uma vez para consultas idênticas,
> gostaria de saber se é nomal ter no log todos estes registros de bind
> também?
> 
Apenas uma vez por sessão (aka conexão), ou seja, novas conexões
precisam executar a análise (parse) da consulta novamente. Além disso,
alterações na estrutura podem forçar o descarte do plano de consulta. O
descarte de planos de uma sessão pode ser feito pelo comando DISCARD PLANS.

> exite algum timeout para que a query realize um novo parse?
> 
Não.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mudar a estrutura da tabela com dependencias de VIEWS

[Fabrízio de Royes Mello]

On 11-01-2016 08:57, lu moraes santos wrote:
> Quando se muda por exemplo  o tamanho de um campo de uma tabela que
> exista views o postgres exige que se apague as dependencias altere e
> depois refaça tais dependencias, isto nao ocorre no sql server, sera que
> existe alguma solucao pra isto no pg??
> 

O PostgreSQL *ainda* não implementa isso, porém você pode analisar as
dependências [1] e facilmente fazer um script para remover VIEWS que
dependam da tabela alvo e depois recriar as mesmas.

Att,


[1] https://wiki.postgresql.org/wiki/Pg_depend_display

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] D

[Gmail]

E

Atenciosamente,
Luiz Henrique
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Schema ou Database distintas?

[Tiago José Adami]

Em 18 de janeiro de 2016 10:01, Felipe Moura  escreveu:
> Pessoal, estamos passando por um situação onde a equipe de banco de dados 
> afirma que trabalhar com esquema no postgres é inseguro e a solução dada 
> seria utilizar uma database para cada sistema.
>
> Alguém já passou por algo parecido?

Depende muito dos conceitos de segurança que a equipe possui. Se
estivessem falando de mais de um database para clientes separados,
onde o esquema do banco é o mesmo, existiriam mais variáveis a serem
consideradas (e mesmo assim não haveria insegurança dadas as
possibilidades de criar um usuário diferente e aplicar os GRANTs
corretamente).

Dou suporte em alguns bancos que tem mais de 20 esquemas, um para cada
departamento. Até hoje nenhum problema com acessos indevidos ou baixo
desempenho por causa disto.

> Também foi argumentado que os relacionamentos entre bases poderia ser feita 
> com dblink sem perda de performance e sem prejudicar futuros relatórios.

Com o DBLink você está adicionando uma camada adicional de comunicação
e na melhor das hipóteses você terá apenas alguns milissegundos de
overhead por requisição. Mas na prática não é mais rápido que acessar
uma tabela do próprio banco de dados alocada no mesmo espaço de
memória que as outras em uso.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[iannsp]

On 1/18/16 2:08 PM, Flavio Henrique Araque Gurgel wrote:
>> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
>> negocio? Pgsql, Java, Perl, Phyton, C?
> 
> Eu só gostaria que parassem de chamar linguagem procedural de regra de
> negócios.
:+1
> 
> As diversas relações, suas colunas e tipos, restrições, chaves e
> esquemas de um banco de dados são uma representação do mundo real, o que
> faz parte da tal "regra de negócios". Uma linguagem procedural
> acrescenta a capacidade de tratamento dos dados dentro do sistema de
> banco dados.
> 
> Podemos mudar um pouco a nomenclatura nesta rica lista de discussões?
> 
:+1
> PostgreSQL não é um saco de dados, pra isso já basta o MongoDB. Lá não
> tem mesmo regra de negócios, é só uma montoeira de informação largada.
> Aí dá pra chamar de "camada de persistência", mas nem isso fazem direito
> naquelas bandas.
:-1
> 
> []s
> Flavio Gurgel
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] PgDay Curitiba - Março de 2016

[ChIcO]

Boa tarde pessoal,

O site do PgDay Curitiba esta oficialmente no ar em
www.pgdaycuritiba.pr.gov.br.

Neste momento estamos recebendo as inscrições de palestrantes até o dia *05
de fevereiro de 2016*.


Lembrando:
*Data*
03 de março de 2016
*Horário*
Das 08:00 às 11:30 e das 13:30 às 18:00
*Local*
Celepar - Companhia de Tecnologia da Informação e Comunicação do Paraná
Rua Mateus Leme, 1561 - Bom Retiro
80520-174 - *Curitiba* - PR - (41) 3200-5000



Gostaria da presença do pessoal aqui da comunidade.

Grato,
Francisco Summa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

[Flávio Alves Granato]

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 de metodos, multiplas linguagens de programação e
níveis de segurança(acesso ao O.S.) creio que a resistencia da
arquitetura é baixa portanto que desenvolvido por um profissional que
saiba o que é arquitetura de software, entenda do nicho em que o
software que esta escrevendo esta inserindo e pratique simplicidade sem
simplismo.
"Creio", "simplicidade" e "simplismo" são palavras que levam a um 
entendimento muito subjetivo e apoiado na experiência pessoal de cada 
um. Entender de nicho não deve ser levado em consideração, mas como um 
adicional pois se contrato um desenvolvedor/DBA eu espero que ele faça 
muito bem é sistemas e que as regras de nicho fiquem muito bem entendida 
pelo negócio, aliás é um dos princípios do SOA ( já falaram por ae que 
SOA não é sistema nem procotolo? ).


No fundo não respondeu à minha pergunta.

Uma lista em ptbr sobre o melhor e mais fodastico banco de dados open
source do mundo.
Concordo contigo, uso ele há mais de 15 anos, mais firme em minha 
memória tenho a versão 7.3 que não me lembro quando foi lançada.

E SÓ VOCE é 110% do tempo desenvolvedor, eu mesmo sou 99% desenvolvedor,
mas com aquele 1%...

não entendi. As vezes tenho dificuldades para entender o sacarmos.

Testes de aceitação são a exposição de um problema. Pense lean.
Pensar "lean" seria desenvolver sem testes e principalmente sem permitir 
aos donos do negócio ter controle sobre as regras e não deveríamos expor 
este problema? Como você responde subjetivamente, me permite endenter 
subjetivamente.


O melhor software que você já escreveu para um cliente é aquele que você
não precisou escrever pq entendeu o problema e resolveu sem uma linha de
código.
Não entendi, se na primeira resposta você me diz que o arquiteto tem que 
entender do nicho para poder ser um bom profissional. Estranho virou um 
paradoxo.

Se você quer resolver o problema do seu cliente você deveria repensar o
seu 110%.

talvez.

"quem trabalha com banco de dados" soou preconceituoso.
Como se os teus 110% não tivesse sido. Mera formalidade de uma discussão 
acalorada não leve a mal.

"Empresas grandes ou pequenas", não importa: Se elas tiverem
programadores dedicados 110% a programar elas terão os mesmos problemas.

Como mudar esta realidade?

"Mercado brasileiro": tem mais gente nessa lista com experiencia
internacional do que você imagina e quanto mais cenarios você conhece
melhor habilitado para analisar o proximo cenario você estará.
Sim, conheço alguns. Já preambulo por esta lista há uns 12 anos. Não é 
de hoje que vejo a discussão de onde ficar as regras de negócio e não é 
a primeira vez que entro nela. Só ler o histórico da lista. ;-)


A diferença que hoje não acho que deva ficar em lugar algo, ou melhor 
dizendo que é melhor estar em algum lugar porque X ou Y disse, como você 
comentou o pragmatismo do movimento Lean leva a se adaptar o tempo todo. 
Na minha concepção o modelo relacional, mesmo que ainda claudicante no 
PostgreSQL e isso não o desmerece pois os outros bancos de dados são 
pernetas mesmo, é a melhor saída para manter a unicidade dos dados, mas 
tem outras respostas que preciso dar quando falamos de sistemas para 
clientes finais, como em uma tela de formulário de cadastro por exemplo 
de um paciênte médico em que eu tenha que colher muitas informações 
sobre a saúde dele e até dados pessoais ( poiseh as vezes que imaginou o 
formulário pecou no design da informação ), o retorno para a tela como 
seria? Dar raise campo a campo não parece ser uma opção muito otimizada 
e "eu" não a escolheria.




"as coisas mudam rapidamente": Ué, modele as mudanças. Se os dados não
fossem considerados mutaveis talvez a profissão de DBA nem existisse.
Fiz várias perguntas e agora que consegue me dar alguma resposta mais 
assertiva? E aliás, só peguei o teu email como exemplo e não foi 
direcionado a você a não ser as 2 ou 3 primeiras linhas.

"temos que acompanhar, o sistema inteiro". Não confunda praticas ruins
de programação com programar.
É prática comum em algumas instituições religiosas a pinçagem de 
palavras ou parte de frases para poder se apoiar e atacar, se conseguir 
ser mais assertivo nas tuas respostas ia ajudar bastante nas discussões.


Senhores já que fomos advertidos, não respondo(do verbo fazer ou 
retrucar) mais emails que tenham tom emocional e direto, há não ser que 
já conheça a pessoa e saiba que ela reagira bem há uma crítica. Para 
evitarmos os flames mesmo... :-)

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Schema ou Database distintas?

[iannsp]

On 1/18/16 10:01 AM, Felipe Moura wrote:
> Bom dia!
> 
> Pessoal, estamos passando por um situação onde a equipe de banco de
> dados afirma que trabalhar com esquema no postgres é inseguro e a
> solução dada seria utilizar uma database para cada sistema.
Schema não é inseguro e é recomendavel exatamente para separar
namespaces de dados com uma relação forte como:
a) Schemas identicos que suportem clientes diferentes.
b) schemas diferentes representando dominios de informação diferentes
sobre uma mesma entidade.

> 
> Alguém já passou por algo parecido?
Sim, eu utilizo schemas no caso A e caso B com sucesso sem apresentar
problema algum relacionado a performance ou organização.
A questão que você precisa ter em mente é que a aplicação de um
migration para schemas de dados identicos vai requerer aplicar o
migration em CADA UM dos schemas.


> 
> Também foi argumentado que os relacionamentos entre bases poderia ser
> feita com dblink sem perda de performance e sem prejudicar futuros
> relatórios. 
Toda vez que você for utilizar o dblink para se relacionar com outra
base você tera de enfrentar primeiro a latencia, depois a questão dos
relacionamentos fracos entre as tabelas(afinal você não vai conseguir
estabelecer triggers utilizando pk/fk) e depois a questão de abrir uma
porta do postgreSQL num ip publico (a não ser que você esteja rodando o
postgresql numa rede privada num DMZ por exemplo).

DBLink levanta mais questões de segurança que o schema, mas no final
elas se resumem a mesma afirmação
se você utilizar o pg_hba de maneira a definir usuarios, algoritmos de
acesso e CIDR's corretos você não tera problemas de segurança.


> 
> Faz sentido?
> 
> Grato!
> 
> 
> -- 
> **
> 
> Atenciosamente,
> 
> Felipe Moura
> Desenvolvedor
> http://about.me/felipewebdf 
> twitter: @felipewebdf
> talk: felipegu...@gmail.com 
> 
> (61) 8490-8156
> 
> 
> /*Não é da benevolência do padeiro, do açougueiro ou do cervejeiro que
> eu espero que saia o meu jantar, mas sim do empenho deles em promover
> seu "auto-interesse".*/
> 
> 
> 
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problema com campo numeric

[Everton Berz]

Oi
vc consegue reproduzir o problema enviando pra nós as instruções SQL
executadas?

--
Everton
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

[iannsp]

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 software em ser alterado no ritmo que a
equipe de negócios precisa mudar é o quanto a arquitetura é capaz de
suportar mudanças nesses pontos.
Uma arquitetura desenvolvida por alguém que desconhece uma área de
negócios normalmente falha em suportar esses hubs de mudança e ai surge
o cenário em que o desenvolvedor luta com o software legado para
encaixar as mudanças. Isso é oq ue chamo taxa de resistencia a mudança
em uma arquitetura de software.

> 
>> No caso do sgdb, principalmente o postgresql que suporta tipagem dos
>> parametros, sobrecarga de metodos, multiplas linguagens de programação e
>> níveis de segurança(acesso ao O.S.) creio que a resistencia da
>> arquitetura é baixa portanto que desenvolvido por um profissional que
>> saiba o que é arquitetura de software, entenda do nicho em que o
>> software que esta escrevendo esta inserindo e pratique simplicidade sem
>> simplismo.
> "Creio", "simplicidade" e "simplismo" são palavras que levam a um
> entendimento muito subjetivo e apoiado na experiência pessoal de cada
> um. Entender de nicho não deve ser levado em consideração, mas como um
> adicional pois se contrato um desenvolvedor/DBA eu espero que ele faça
> muito bem é sistemas e que as regras de nicho fiquem muito bem entendida
> pelo negócio, aliás é um dos princípios do SOA ( já falaram por ae que
> SOA não é sistema nem procotolo? ).
Pois bem, com todo o respeito: discordo completamente.
 Levar o profissional técnico conhecer de técnica sem conhecer o
contexto é contra o que acredito.
 DDD e lean, conceitos que uso no desenvolvimento de sistemas, se
referem a isso.
 Sim, as palavras creio, simplicidade e simplismo são de aplicação
pessoal, mas não são de meu uso exclusivo e tampouco são subjetivas.

> 
> No fundo não respondeu à minha pergunta.
entendo.
>> Uma lista em ptbr sobre o melhor e mais fodastico banco de dados open
>> source do mundo.
> Concordo contigo, uso ele há mais de 15 anos, mais firme em minha
> memória tenho a versão 7.3 que não me lembro quando foi lançada.
puxa.
>> E SÓ VOCE é 110% do tempo desenvolvedor, eu mesmo sou 99% desenvolvedor,
>> mas com aquele 1%...
> não entendi. As vezes tenho dificuldades para entender o sacarmos.
entendo.
>> Testes de aceitação são a exposição de um problema. Pense lean.
> Pensar "lean" seria desenvolver sem testes e principalmente sem permitir
> aos donos do negócio ter controle sobre as regras e não deveríamos expor
> este problema? Como você responde subjetivamente, me permite endenter
> subjetivamente.
>>
>> O melhor software que você já escreveu para um cliente é aquele que você
>> não precisou escrever pq entendeu o problema e resolveu sem uma linha de
>> código.
> Não entendi, se na primeira resposta você me diz que o arquiteto tem que
> entender do nicho para poder ser um bom profissional. Estranho virou um
> paradoxo.
é necessario entender de negócio para resolver um problema sem programar.

>> Se você quer resolver o problema do seu cliente você deveria repensar o
>> seu 110%.
> talvez.
>> "quem trabalha com banco de dados" soou preconceituoso.
> Como se os teus 110% não tivesse sido. Mera formalidade de uma discussão
> acalorada não leve a mal.
>> "Empresas grandes ou pequenas", não importa: Se elas tiverem
>> programadores dedicados 110% a programar elas terão os mesmos problemas.
> Como mudar esta realidade?
Parar de acreditar que todo problema exige código em sua solução e que
programar mais resolve mais problemas. É a famosa parabola do velho
lenhador, aqui tem um video para ilustrar melhor:
https://www.youtube.com/watch?v=RGHs8zgZMh0

>> "Mercado brasileiro": tem mais gente nessa lista com experiencia
>> internacional do que você imagina e quanto mais cenarios você conhece
>> melhor habilitado para analisar o proximo cenario você estará.
> Sim, conheço alguns. Já preambulo por esta lista há uns 12 anos. Não é
> de hoje que vejo a discussão de onde ficar as regras de negócio e não é
> a primeira vez que entro nela. Só ler o histórico da lista. ;-)
> 
> A diferença que hoje não acho que deva ficar em lugar algo, ou melhor
> dizendo que é melhor estar em algum lugar porque X ou Y disse, como você
> comentou o pragmatismo do movimento Lean leva a se adaptar o tempo todo.
> Na minha concepção o modelo relacional, mesmo que ainda claudicante no
> PostgreSQL e isso não o desmerece pois os outros bancos de dados são
> pernetas mesmo, é a melhor saída para manter a unicidade dos dados, mas
> tem outras respostas que preciso dar quando falamos de sistemas para
> clientes finais, como em uma tela de formulário de cadastro por exemplo
> de um paciênte médico em que eu tenha que colher muitas informações
> sobre a saúde dele e até dados pessoais ( 

[pgbr-geral] Schema ou Database distintas?

[Felipe Moura]

Bom dia!

Pessoal, estamos passando por um situação onde a equipe de banco de dados
afirma que trabalhar com esquema no postgres é inseguro e a solução dada
seria utilizar uma database para cada sistema.

Alguém já passou por algo parecido?

Também foi argumentado que os relacionamentos entre bases poderia ser feita
com dblink sem perda de performance e sem prejudicar futuros relatórios.

Faz sentido?

Grato!


-- 

Atenciosamente,

Felipe Moura
Desenvolvedor
http://about.me/felipewebdf
twitter: @felipewebdf
talk: felipegu...@gmail.com

(61) 8490-8156


*Não é da benevolência do padeiro, do açougueiro ou do cervejeiro que eu
espero que saia o meu jantar, mas sim do empenho deles em promover seu
"auto-interesse".*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2016-01-18 13:58 GMT-02:00 Douglas Fabiano Specht :
> Vamos utilizar o Postgresql 9.5 como Banco de dados Default, mas pode
> ocorrer de termos clientes com Oracle, logo já precisamos nos preparar.
> O que eu queria era recomendações:
> 1-Ferramenta de modelagem multi banco e colaborativo(open-source de
> preferencia)

Eu prefiro lidar com código fonte e gerar os diagramas a partir dele.
Para isso temos SQL::Fairy, pgAutodoc e uma terceira alternativa, mais
moderna, cujo nome me escapa mas que algum colega logo lembrará.


> 2-Ferramenta para debug

Não é minha praia, passo.


> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
> negocio? Pgsql, Java, Perl, Phyton, C?

SQL sempre que possível: quanto mais regras forem programadas
declarativamente, como restrições de integridade, melhor.  Como o
Gurgel já nos lembrou carinhosamente.

Para padronização do restante, que não coube em restrições de
integridade, o ideal seria o ISO SQL/PSM…


> 4-Pensando em multi banco, qual das linguagens eu poderia aproveitar no
> postgresql e tambem no Oracle

…entretanto, o Oracle não implementa SQL/PSM.  Quem implementa são, se
não me falha a memória, IBM DB/2 (o original), SAPdb (ou seja lá qual
o último nome do MaxDB), MySQL (e possivelmente alguns derivados menos
cotados) e PostgreSQL.

Até onde sei, há apenas duas linguagens em comum entre Oracle e
PostgreSQL: PL/Java e PL/pgSQL (PL/SQL no Oracle).

O PL/pgSQL tem a vantagem de ser mais próximo do SQL/PSM
especificamente, e do SQL em geral; o Java tem a vantagem de existir
em outros SGBDs, e ser mais familiar para um certo tipo de
programador.

Isso dito, sei muito pouco, estou afastado do Oracle há mais de cinco
anos, então seria possível que eles tenham implementado SQL/PSM ou
outras linguagens.  É possível, mas eu duvide-o-dó.  Tarefa de casa,
pesquisar.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Oferta de trabalho PostgreSQL na Alemanha - Com visto para trabalho

[Tiago José Adami]

Olá pessoal.

Recentemente fui contactado via LinkedIN por um recrutador chamado
Sebastian White. Ele está procurando um profissional em PostgreSQL que
tenha bons conhecimentos em otimização, upgrades, incidentes e shell script
(Python é um "plus a mais") para trabalhar em Berlin, sendo necessário
inglês avançado/fluente.

Eu não conheço o Sebastian, apenas troquei alguns e-mails com ele. Não
parece ser uma falsa proposta, inclusive as entrevistas iniciais serão
feitas por Skype. Confesso que fiquei muito interessado na proposta, mas
por motivos pessoais não posso sair do Brasil e não segui adiante.

Logo, quem possuir interesse entre em contato com Sebastian pelo LinkedIN:
https://www.linkedin.com/in/sebastian-white-13272b26

...ou envie um e-mail solicitando mais informações sobre a vaga ao
endereço: sebastian -at- stelfox -dot- ie

Abaixo conteúdo do e-mail que recebi:

"""
I am working on behalf of Delivery Hero based in Berlin(English speaking),
one of the largest online food ordering companies in the world, now
operating on 3 continents with 15 million monthly transactions and 1600
staff.

Their DBA team is need of a postgresql champion, who has been using it
competently for the last few years in a Linux environment. Optimization,
upgrades, provisions and incidents will be all daily challenges, and you
will get to work in a talented and vibrant IT department. Some scripting
work in Bash and python will also come up
http://career.deliveryhero.com/

The company offer visas, relocation assistance, company benefits like
insurance, new hardware, social events and tech days. Also the chance to
work in Europe's silicon valley, the epicentre of Europe's start up
revolution.

If you know anyone who would be interested in this great new working
opportunity, please let me know, and I will contact them.

All the best and thanks for your time!

Sebastian

Sebastian White
01 679 3182 | sebastian -at- stelfox -dot- ie
"""

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Flavio Henrique Araque Gurgel]

3-Qual linguagem voces recomendariam para desenvolver essas Regras de
negocio? Pgsql, Java, Perl, Phyton, C?


Eu só gostaria que parassem de chamar linguagem procedural de regra de 
negócios.


As diversas relações, suas colunas e tipos, restrições, chaves e 
esquemas de um banco de dados são uma representação do mundo real, o que 
faz parte da tal "regra de negócios". Uma linguagem procedural 
acrescenta a capacidade de tratamento dos dados dentro do sistema de 
banco dados.


Podemos mudar um pouco a nomenclatura nesta rica lista de discussões?

PostgreSQL não é um saco de dados, pra isso já basta o MongoDB. Lá não 
tem mesmo regra de negócios, é só uma montoeira de informação largada. 
Aí dá pra chamar de "camada de persistência", mas nem isso fazem direito 
naquelas bandas.


[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Douglas Fabiano Specht]

boa tarde pessoal,
depois da fervorosa discussão na Thread  "Regras de negocio no banco ou na
aplicação" gostaria de algumas sugestões para montagem de um ambiente de
desenvolvimento.
Vamos utilizar o Postgresql 9.5 como Banco de dados Default, mas pode
ocorrer de termos clientes com Oracle, logo já precisamos nos preparar.
O que eu queria era recomendações:
1-Ferramenta de modelagem multi banco e colaborativo(open-source de
preferencia)
2-Ferramenta para debug
3-Qual linguagem voces recomendariam para desenvolver essas Regras de
negocio? Pgsql, Java, Perl, Phyton, C?
4-Pensando em multi banco, qual das linguagens eu poderia aproveitar no
postgresql e tambem no Oracle


-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Oferta de trabalho PostgreSQL na Alemanha - Com visto para trabalho

[Rafael Fialho]

2016-01-18 14:42 GMT-02:00 Tiago José Adami :

> Olá pessoal.
>
> Recentemente fui contactado via LinkedIN por um recrutador chamado
> Sebastian White. Ele está procurando um profissional em PostgreSQL que
> tenha bons conhecimentos em otimização, upgrades, incidentes e shell script
> (Python é um "plus a mais") para trabalhar em Berlin, sendo necessário
> inglês avançado/fluente.
>
> Eu não conheço o Sebastian, apenas troquei alguns e-mails com ele. Não
> parece ser uma falsa proposta, inclusive as entrevistas iniciais serão
> feitas por Skype. Confesso que fiquei muito interessado na proposta, mas
> por motivos pessoais não posso sair do Brasil e não segui adiante.
>
> Logo, quem possuir interesse entre em contato com Sebastian pelo LinkedIN:
> https://www.linkedin.com/in/sebastian-white-13272b26
>
> ...ou envie um e-mail solicitando mais informações sobre a vaga ao
> endereço: sebastian -at- stelfox -dot- ie
>

Obrigado por compartilhar, Tiago!

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Rafael Bernard Rodrigues Araujo]

Recomendo também ter um repositório com controle de versão das
funções/procedimentos.

2016-01-18 13:58 GMT-02:00 Douglas Fabiano Specht 
:

>
> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
> negocio? Pgsql, Java, Perl, Phyton, C?
>


PL/PGSQL para PostgreSQL e PL/SQL para Oracle.



> 4-Pensando em multi banco, qual das linguagens eu poderia aproveitar no
> postgresql e tambem no Oracle
>


São duas linguages diferentes, então será necessário ter a versão da função
em cada linguagem mesmo.

Rafael
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Douglas Fabiano Specht]

Em 18 de janeiro de 2016 14:08, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
>> negocio? Pgsql, Java, Perl, Phyton, C?
>>
>
> Eu só gostaria que parassem de chamar linguagem procedural de regra de
> negócios.
>

Mas linguagem procedural é para criar regras de negocio de uma aplicação no
banco.
Digamos validação de CNPJ ou de telefone, nao vou ter isso na nossa
aplicação delphi e sim no banco de dados em algum linguagem, perl,
java,pgsql, etc..


> As diversas relações, suas colunas e tipos, restrições, chaves e esquemas
> de um banco de dados são uma representação do mundo real, o que faz parte
> da tal "regra de negócios". Uma linguagem procedural acrescenta a
> capacidade de tratamento dos dados dentro do sistema de banco dados.
>
> Podemos mudar um pouco a nomenclatura nesta rica lista de discussões?
>
> PostgreSQL não é um saco de dados, pra isso já basta o MongoDB. Lá não tem
> mesmo regra de negócios, é só uma montoeira de informação largada. Aí dá
> pra chamar de "camada de persistência", mas nem isso fazem direito naquelas
> bandas.
>
> []s
> Flavio Gurgel
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Douglas Fabiano Specht]

Em 18 de janeiro de 2016 19:57, Tiago José Adami 
escreveu:

>
> Em 18/01/2016 19:35, "Douglas Fabiano Specht" 
> escreveu:
> >
> >
> >
> > Em 18 de janeiro de 2016 14:08, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
> >>>
> >>> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
> >>> negocio? Pgsql, Java, Perl, Phyton, C?
> >>
> >>
> >> Eu só gostaria que parassem de chamar linguagem procedural de regra de
> negócios.
> >
> >
> > Mas linguagem procedural é para criar regras de negocio de uma aplicação
> no banco.
> > Digamos validação de CNPJ ou de telefone, nao vou ter isso na nossa
> aplicação delphi e sim no banco de dados em algum linguagem, perl,
> java,pgsql, etc..
>
> Agora chegamos em um ponto interessante da discussão:
> Regras de validação de campo, por exemplo, você poderá (deverá) fazer no
> banco para garantir a integridade dos dados. Mas também precisará ter algo
> no front-end para diminuir o tempo de resposta e distribuir mesmo que pouca
> coisa o processamento.
>
> O que eu vejo de toda a discussão só reafirma meu pensamento inicial: ter
> tudo no banco ou tudo na aplicação não parece ser a melhor saída quando há
> inúmeras ferramentas que agilizam um ou outro lado. Geralmente - e não
> estou apontando para alguém aqui na lista - alguém decide pôr tudo em
> apenas um lado porque não conhece o outro.
>
> Acredito que nada pode ser decidido sem uma grande avaliação dos
> requisitos da aplicação/sistema, bem como o seu ambiente de execução.
>
> Tiago J. Adami
> Enviado do GMail / Android
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Tiago
muito boa a sua abordagem, nesse novo projeto a ideia não é ter tudo no
banco, algumas coisas mais pesadas deixar que o banco faça o processamento,
exemplo gerar o arquivo de sped.
esse arquivo é minerado muitos dados, logo se a regra estaria na aplicação,
teria que fazer vários selects o que poderia ter um grande volume de
trafego de rede entre aplicação e banco, logo posso gerar o aquivo direto
pelo banco ou devolver os dados mastigados e a aplicação somente gerar o
arquivo.
Claro que devemos analisar caso a caso, e esse foi somente um exemplo.
mas de ferramenta para debug niguem mais?

-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Tiago José Adami]

Em 18/01/2016 19:35, "Douglas Fabiano Specht" 
escreveu:
>
>
>
> Em 18 de janeiro de 2016 14:08, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
>>>
>>> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
>>> negocio? Pgsql, Java, Perl, Phyton, C?
>>
>>
>> Eu só gostaria que parassem de chamar linguagem procedural de regra de
negócios.
>
>
> Mas linguagem procedural é para criar regras de negocio de uma aplicação
no banco.
> Digamos validação de CNPJ ou de telefone, nao vou ter isso na nossa
aplicação delphi e sim no banco de dados em algum linguagem, perl,
java,pgsql, etc..

Agora chegamos em um ponto interessante da discussão:
Regras de validação de campo, por exemplo, você poderá (deverá) fazer no
banco para garantir a integridade dos dados. Mas também precisará ter algo
no front-end para diminuir o tempo de resposta e distribuir mesmo que pouca
coisa o processamento.

O que eu vejo de toda a discussão só reafirma meu pensamento inicial: ter
tudo no banco ou tudo na aplicação não parece ser a melhor saída quando há
inúmeras ferramentas que agilizam um ou outro lado. Geralmente - e não
estou apontando para alguém aqui na lista - alguém decide pôr tudo em
apenas um lado porque não conhece o outro.

Acredito que nada pode ser decidido sem uma grande avaliação dos requisitos
da aplicação/sistema, bem como o seu ambiente de execução.

Tiago J. Adami
Enviado do GMail / Android
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Dickson S. Guedes]

Em 18 de janeiro de 2016 19:35, Douglas Fabiano Specht
 escreveu:
> Em 18 de janeiro de 2016 14:08, Flavio Henrique Araque Gurgel
>  escreveu:
>>>
>>> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
>>> negocio? Pgsql, Java, Perl, Phyton, C?
>>
>>
>> Eu só gostaria que parassem de chamar linguagem procedural de regra de
>> negócios.
>
>
> Mas linguagem procedural é para criar regras de negocio de uma aplicação no
> banco.

É que o que o Flávio quis dizer é que vocẽ pode criar regras de
negócio utilizando uma PL, mas não são, necessariamente, as únicas
regras. Alguns exemplo podem ser, regra de unicidade você utiliza uma
UNIQUE KEY ou uma PRIMARY KEY, você verifica se um dado esta dentro de
um dominio esperado utilizando o tipo certo como numeric, int4, int8,
json, varchar, varchar(15), etc. Você pode ter uma CONSTRAINT CHECK
para verificar se a idade do indivíduo a ser inserido é maior ou não
que 18 e por ai vai. Ou seja, você consegue impor muitas regras sem
escrever uma PL sequer, e é isto que as vezes confunde.

> Digamos validação de CNPJ ou de telefone, nao vou ter isso na nossa
> aplicação delphi e sim no banco de dados em algum linguagem, perl,
> java,pgsql, etc..

Você pode por na aplicação E no banco. Seu banco pode ter um tipo CPF
[1] mas suas aplicações podem validar também. Lembre-se que em muitos
cenários você não tem uma única aplicação executando e reforçar regras
no banco é importante, porém nem sempre as PLs são as únicas maneiras
de fazê-lo.


[1] https://github.com/guedes/validadores

[]s
-- 
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral