Re: [pgbr-geral] Vagas pra ETL e BI

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 11:16 GMT-03:00 Rebert Tomaz Aquino :
> Pessoal, desculpem estar enviando a mensagem de forma automatizada

Como faz para marcar /spam/ nesta lista?  Não achei uma interface para
isso em 
https://listas.postgresql.org.br/pipermail/pgbr-geral/2016-June/043191.html



-- 
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] Problemas com ‘alternativas’ ao modelo relacional

[Guimarães Faria Corcete DUTRA , Leandro]

https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.phpzbdxtf

E isso é o mais famoso hoje.  Infelzmente, já tão popular que, em vez
de voltar para o mundo relacional, provavelmente vão conviver com o
problema, talvez gambiarrá-lo, e mesmo que se resolva será só esperar
o próximo… quem não aprende com a história (de que necessidades e
problemas o modelo relacional começou a resolver), está condenado a
repeti-la — como farsa.


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 16:00 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
> Em 7 de junho de 2016 15:42, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>>> Na questão do OP, se algum ORM for utilizado com classes de entidade
>>> estáticas no aplicativo não haverão muitos problemas - desde que os
>>> novos atributos não sejam /not null/ e/ou tenham valores default.
[…]
>> Certo.  Mas isso implica em restrições importantes, no caso serem
>> entidades estáticas e todos os novos atributos terem valor padrão ou
>> serem NULáveis — e o ideal é não ser NULável.
>
> Concordo. Mas aí vai depender do contrato com o cliente para avaliar
> quanto tempo é possível parar o ambiente para alguma atualização - com
> tempo suficiente para atualizar todas as instâncias do App e também o
> banco de dados. Caso contrário, é preciso se render a alguns NULLs.

Verdade, e isso é muito triste.

A maneira que você colocou me fez lembrar de outro aspecto: talvez
seja mais produtivo, dependendo da situação, pensar mais em coordenar
as mudanças nos servidores de aplicação do que fazer malabarismos com
os dados.  Deixando a questão contratual para o infame ceteris
paribus.


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 15:30 GMT-03:00 Michel Luiz Milezzi :
>> 2016-06-07 14:03 GMT-03:00 Michel Luiz Milezzi :
>> >> Não consigo imaginar uma maneira sistemática e (ou) automática.
>> >> Dependendo das alterações, você pode criar visões que preservem o
>> >> esquema lógico anterior, mas é trabalho braçal.
>> >
>> > Também não consigo ver uma forma de colocar isso na prática. Talvez seja
>> > o caso de recorrer a um banco de dados semi-estruturado, não relacional.
>>
>> Isso seria arrancar o nariz porque achou a cara feia.  Para começo, o
>> SQL também não é exatamente relacional, e isso (via dificuldades de
>> atualização de visões e outros probleminhas decorrentes de violações
>> do modelo relacional) é justamente uma das coisas que atrapalha esse
>> tipo de trabalho.
>
> Em qual momento afirmei que SQL É estritamente relacional?

Não afirmou, pressupôs.  Sua solução implica em que o problema é ser
relacional, quando é justamente o contrário: não ser relacional é que
complica o problema (que existe de qualquer maneira, mas não precisava
ser tão grave).


> Não entendi essa
> sua colocação. Você distorceu o que eu disse.

Não distorci, você que entrou em modo de defesa.  Vamos com calma que
chegamos lá.


> Banco de dados 'semi-estruturado' não existe?

Não, não existe.  Por que estrutura ou há, ou não há; e se não há
estrutura, há caos, não dados.  Dados por definição são estruturados,
o resto é márquetim.


> Nem vou discutir muito com
> você, basta uma olhada rápida na página do MongoDB para essa sua afirmação
> cair por terra:

O Mongo é contraexemplo de sanidade conceitual.  Ele afirmar o
contrário só ajuda a comprovar o que queremos explicar.


> No mais, semi-estruturado não quer dizer que esteja mal definido. Não
> generalize os seus casos, por favor.

Generalizo, sim.  Porque se não tem ao menos os conceitos relacionais,
isso já é má definição.  Nada ainda substitui o modelo relacional,
mesmo que numa implementação ruim como é a do SQL — mesmo ruim é
melhor que todas as outras que são ainda mais distantes do modelo.


>> Isso nada tem a ver com ORM.  ORM no caso vai é acrescentar
>> complexidade numa abordagem muito simples, e geralmente insuficiente,
>> que é de somente criar novos objetos.
>
> Veja, se as duas aplicações do amigo já estiverem usando um ORM para
> consumir o mesmo banco de dados, é possível utilizar mapeamento diferente
> nestas duas aplicações, desde que você não altere o tipo ou remova as
> colunas das tabelas que estão mapeadas. Você entendeu o que eu quis dizer?
> Não estou afirmando que é para adotar um ORM, estou dizendo que se o mesmo
> já for utilizado, é possível manter as duas entidades diferentes diante
> daquelas condições.

Mas não são duas aplicações, até onde entendi, mas dois servidores de
aplicação com duas versões diferentes dos mesmos aplicativos.  Posso
estar enganado, como sói acontecer.

De qualquer maneira, permanece meu ponto: a questão aí não é usar ORM
ou um gerador qualquer de código, é a disciplina de acrescentar ou
aumentar, sem remover, alterar ou diminuir.


>> > De qualquer forma não recomendo estes cenários, o ideal é você tratar
>> > isto a
>> > nível de aplicação. Por exemplo, é possível criar um ponto comum de
>> > acesso
>> > ao banco para as duas aplicações através de um servidor REST. Este
>> > servidor
>> > poderia tratar as diferenças entre as aplicações pela versão da sua api
>> > de
>> > comunicação.
>>
>> Como mudam os nomes!  Antes do Rest, chamávamos isso de três camadas.
>> E implementávamos na própria base de dados, com as PLs.  Não que isso
>> anule o Rest; mas Rest é para outros casos, e incidentalmente pode
>> ajudar nisso também.  Em outras palavras, a questão aqui não é ser
>> Rest, é isolar a apresentação (servidor de aplicações, no caso) da
>> lógica (PLs, Rest, o que for).
>
>
> Qual parte do "por exemplo" você não entendeu?

Nenhuma.  O exemplo é válido, só estou falando que não precisa ser
Rest, basta separar a apresentação da lógica.


> Vejo que você tem dificuldade
> em aceitar a opinião alheia, então não vou me alongar muito na discussão

Vou ignorar o ad hominem.


> mas Rest também é usado para estes casos, a nova stack da google, por
> exemplo, utiliza esta abordagem muito bem. Neste caso, o frontend
> (AngularJS) comunica com o backend (endpoints REST) em um modelo MVC.

CQD, o importante aí é o MVC, não o Rest.

Vamos com calma que a gente aprende.  Se defendendo não crescemos.


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 15:40 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
> Em 7 de junho de 2016 15:16, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>> 2016-06-07 15:10 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
>>>
>>> Só é preciso cuidado especial com as ferramentas "geradoras de
>>> código", aquelas que se baseiam na estrutura (catálogo) do banco de
>>> dados para montar comandos SQL.
>>
>> O que inclui os famigerados ORM, certo?
>
> Na questão do OP, se algum ORM for utilizado com classes de entidade
> estáticas no aplicativo não haverão muitos problemas - desde que os
> novos atributos não sejam /not null/ e/ou tenham valores default.
> Haveriam problemas caso atributos ou tabelas fossem eliminados.

Certo.  Mas isso implica em restrições importantes, no caso serem
entidades estáticas e todos os novos atributos terem valor padrão ou
serem NULáveis — e o ideal é não ser NULável.


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 15:32 GMT-03:00 Michel Luiz Milezzi <michelmile...@gmail.com>:
> Em 7 de junho de 2016 15:16, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>>
>> 2016-06-07 15:10 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
>> >
>> > Só é preciso cuidado especial com as ferramentas "geradoras de
>> > código", aquelas que se baseiam na estrutura (catálogo) do banco de
>> > dados para montar comandos SQL.
>>
>> O que inclui os famigerados ORM, certo?
>
> ORM usam as entidades que foram previamente mapeadas para a geração dos
> comandos SQL e não o dicionário de dados.

Depende, há ORMs que trabalham com dicionários preexistentes.   São os
mais razoáveis, aliás.

De qualquer maneira, o problema em tela é o mesmo, até onde entendo.


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 15:10 GMT-03:00 Tiago José Adami :
>
> Só é preciso cuidado especial com as ferramentas "geradoras de
> código", aquelas que se baseiam na estrutura (catálogo) do banco de
> dados para montar comandos SQL.

O que inclui os famigerados ORM, certo?


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 14:03 GMT-03:00 Michel Luiz Milezzi :
>> Não consigo imaginar uma maneira sistemática e (ou) automática.
>> Dependendo das alterações, você pode criar visões que preservem o
>> esquema lógico anterior, mas é trabalho braçal.
>
> Também não consigo ver uma forma de colocar isso na prática. Talvez seja o
> caso de recorrer a um banco de dados semi-estruturado, não relacional.

Isso seria arrancar o nariz porque achou a cara feia.  Para começo, o
SQL também não é exatamente relacional, e isso (via dificuldades de
atualização de visões e outros probleminhas decorrentes de violações
do modelo relacional) é justamente uma das coisas que atrapalha esse
tipo de trabalho.

Depois, um ‘semi-estruturado’ não existe; o que existe é uma estrutura
não tão bem definida quanto pode ser em SQL.  E quanto mais mal
definida, maior a dificuldade de lidar com versões e suas
conseqüências.  No caso, ‘semi-estruturar’ é varrer a sujeira para
debaixo do tapete, e esperar que não tenha ninguém alérgico na sala…


> Mas, se você utilizar um ORM para abstrair as consultas no banco de dados é
> possível manter as entidades mapeadas de forma "diferente" em cada
> aplicação. Neste cenário somente seria possível adicionar objetos novos no
> banco de dados. Daria problema, por exemplo, se uma coluna fosse removida e
> a mesma continuasse no mapeamento da entidade em questão em uma das versões
> da sua aplicação.

Isso nada tem a ver com ORM.  ORM no caso vai é acrescentar
complexidade numa abordagem muito simples, e geralmente insuficiente,
que é de somente criar novos objetos.


> De qualquer forma não recomendo estes cenários, o ideal é você tratar isto a
> nível de aplicação. Por exemplo, é possível criar um ponto comum de acesso
> ao banco para as duas aplicações através de um servidor REST. Este servidor
> poderia tratar as diferenças entre as aplicações pela versão da sua api de
> comunicação.

Como mudam os nomes!  Antes do Rest, chamávamos isso de três camadas.
E implementávamos na própria base de dados, com as PLs.  Não que isso
anule o Rest; mas Rest é para outros casos, e incidentalmente pode
ajudar nisso também.  Em outras palavras, a questão aqui não é ser
Rest, é isolar a apresentação (servidor de aplicações, no caso) da
lógica (PLs, Rest, o que for).


-- 
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

Re: [pgbr-geral] versão de schemas

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-07 13:41 GMT-03:00 Douglas Fabiano Specht :
> Pessoal boa tarde,
> alguem trabalha ou ja trabalhou, ou ainda poderia contribuir com informações
> sobre como controlar versoes de diferentes no mesmo schema?
> Digamos, tenho 2 servidores de aplicação e 1 de banco de dados:
> quando eu atualizar o servidor de aplicação 01, ele irá alterar a ddl do
> schema, mas os clientes que estão conectados no servidor 02 teriam que olhar
> ainda para uma versão anterior do schema.
> isso é possivel?

Não consigo imaginar uma maneira sistemática e (ou) automática.
Dependendo das alterações, você pode criar visões que preservem o
esquema lógico anterior, mas é trabalho braçal.

O ideal aí é atualizar as aplicações juntas, ou tirar um dos
servidores do ar enquanto atualiza o outro.


-- 
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

Re: [pgbr-geral] Problemas no UPSERT

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-26 11:09 GMT-03:00 Alan Tavares :
> Estou com um problema no UPSERT estou usando o PG 9.5 e usando o recurso
[…]

Não consegui entender.  Pode pontuar e separar frases, talvez
parágrafos, para a gente ver se entende?

Obrigado antecipadamente.


-- 
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

Re: [pgbr-geral] PGSQL_TMP

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-14 19:19 GMT-03:00 Raphael Coutinho :
>
> Estou querendo separar o pgsql_tmp do disco SSD e colocar no SAS. Já que o
> forte do SSD é leitura, acredito que separar esse diretório vai me trazer um
> ganho de performance, conservar a vida útil do SSD.

SAS, até onde sei, é ortogonal a SSD.  Ou não?

Distribuir costuma ser uma boa idéia.  Mas SSD é bem mais rápido que
as alternativas mesmo para escrita.  Distribuir para algo mais lento
pode não ser boa idéia, se o SSD não for gargalo atualmente.


-- 
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

Re: [pgbr-geral] Migrando Postgresql que versão usar ?

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-13 9:52 GMT-03:00 Raphael Coutinho :
>
>> >Eu optaria pela versão 9.4.
>>
>> Por quê?
>
> Sempre fico meio pé atrás com últimas versões.

Não generalize, por favor.  O PostgreSQL tem uma qualidade tanto de
base de código quanto de processo de atualização inigualável.

E leve em conta o processo.  Α 9.5 não foi lançada hoje de manhã, já
está sendo amplamente usada e não tem defeitos graves conhecidos, ao
contrário da concorrência.  A transparência no tratamento de defeitos
também é total.  E o consulente está planejando uma migração; até ela
ir para produção, certamente a segurança com a 9.5 já estará ainda
mais estabelecida do que já está, e que já é suficiente para qualquer
aplicativo Delphi que eu consiga imaginar.


-- 
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

Re: [pgbr-geral] Res: Re: Res: Re: Res: Re: Res: Re: Postgres x GBuster ouSistemasBancos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-10 21:08 GMT-03:00 Euler Taveira :
> A solução é relatar o problema a detentora da prag^H^H^H programa (GAS)
> através do endereço supportgas at diebold dot com relatando o problema
> e informando todas as versões do PostgreSQL que estão com problema. Eles
> devem ter um lista de softwares "seguros" (homologados) e eles devem
> incluir o Postgres.

Euler, por favor me esclareça.  Você acha que o gBuster está
interferindo no PostgreSQL por considerá-lo inseguro?

Confesso que essa possibilidade não me ocorreu.  Estava pensando em
interferência acidental, por (falta de) qualidade do gBuster.


-- 
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

Re: [pgbr-geral] Res: Res: Re: Res: Re: Res: Re: Postgres x GBuster ouSistemasBancos

[Guimarães Faria Corcete DUTRA , Leandro]

Por favor, siga nosso exemplo e escreva em texto simples, com os
marcadores padrão de início de linha de citação >.  Está difícil
entender suas respostas.  Evite formatação, cores, marcadores fora de
padrão como linhas de traços, e preserve a informação de a quem
responde.

Olhe abaixo como fica tua mensagem num cliente texto.


2016-04-08 9:10 GMT-03:00 fors...@forsell.com.br :
>
>
> Apenas para registrar o fato, também estamos com esse problema, em
>
> menor escala mas vem acontecendo...
>
>
>
> São máquinas com Windows 10 64bits, com PostgreSQL 9.2.3, em 2
>
> máquinas que apresentam essa situação, diferente do amigo, não possuem
>
> instalados qualquer aplicativo de banco (GBuster, etc). Nesses nossos
>
> casos o serviço simplesmente para... mas o PostgreSQL ainda esta on,
>
> no entanto não aceita mais conexões...
>
>
>
> Como são máquinas de desenvolvedores e nosso sistema ainda não esta
>
> homologado para Windows 10 acabamos deixando de lado esse problema
>
>
>
>> Primeiro que o equipamento tem de ser decente, não descente. Se ele desce,
> é por causa do MS Windows talvez, mas isso não vem ao caso. O Gurgel já
> pediu informações sobre carga.
>
>
>
> Também acho que o problema esta relacionado com o SO Windows, pode ser
>
> permissões no diretório pgdata, mas não identifiquei essa situação nos
>
> nossos casos... Ou então algo relacionado ao gerenciamento de
>
> usuários...
>
>
>
> Att.
>
>
>
> --
>
> Legal, é mais uma situação que pode descartar ser o GBuster, aqui também,
> minha máquina local, simplesmente para e só volta a funcionar quando o
> computador é reiniciado
>
> qualquer tentativa de fazer o serviço voltar falhou
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



-- 
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

Re: [pgbr-geral] Res: Re: Res: Re: Res: Re: Postgres x GBuster ou SistemasBancos

[Guimarães Faria Corcete DUTRA , Leandro]

Por favor, evite enviar mensagens formatadas em HTML ou similares.
Prefira texto puro, simples.  No caso, a maneira como você respondeu
ocultou quem realmente escreveu o que respondeste.


2016-04-08 8:28 GMT-03:00 fors...@forsell.com.br :
>
> O que não faz sentido é o fato de você permitir que seu servidor de dados 
> seja utilizado por usuários para acessos a internet
> banking e outros bichos. Eu não entendí essa parte. Por acaso você instala 
> sua aplicação com o banco de dados localmente em cada
> usuário?

Sim, ele instala.  Aparentemente, você não entendeu a situação que o
colega descreveu.  Não são servidores, são máquinas de usuário onde
ele tem algumas bases locais, por alguma razão que não vem ao caso.
Isso é perfeitamente normal.  Podem ser máquinas de programadores que
por alguma razão precisam do MS Windows, nem que seja por
incompetência; pode ser algum aplicativo que precise do PostgreSQL e
que não valha a pena ter as bases em servidores.

Por favor, pensem um pouco antes de responder.  Eu sou totalmente a
favor de questionar coisas estúpidas que às vezes alguns consulentes
fazem, mas precisa ao menos pensar um pouco na situação da pessoa
antes de lhe dizer algo óbvio.



-- 
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

Re: [pgbr-geral] Res: Re: Res: Re: Res: Re: Postgres x GBuster ou SistemasBancos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-08 7:58 GMT-03:00 André Geraldo dos Santos :
>
> Adote sistemas operacionais especializados em prover/servir acesso à 
> aplicações e dados, use Linux seja feliz e durma em paz.

Colega, por favor leve em consideração a circunstância do colega
consulente.  Ele deixou bem claro, embora implicitamente, que precisa
do PostgreSQL em máquinas de usuário, não especializadas.  Se não, não
faria sentido se preocupar gBuster.  Ninguém dá tiro no pé de rodar
gBuster em servidor.

Amiúde não podemos fazer o que queremos.


> Não sei qual é o tamanho do seu banco de dados e tão pouco o número de 
> acessos e transações simultâneos,  no entanto, é recomendável que você 
> utilize um hardware descente para a sua operação.

Primeiro que o equipamento tem de ser decente, não descente.  Se ele
desce, é por causa do MS Windows talvez, mas isso não vem ao caso.  O
Gurgel já pediu informações sobre carga.


> As minhas dicas podem não lhe ajudar diretamente no problema, mas sem dúvida 
> servem de base para evitar esse tipo de problema.

Não é verdade, foram generalidades absolutamente inúteis para quem não
pode abandonar sistemas proprietários.



-- 
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

Re: [pgbr-geral] Res: Re: Res: Re: Postgres x GBuster ou Sistemas Bancos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-07 18:38 GMT-03:00 Vinicius Santos :
>
> Minha solução foi utilizar uma máquina exclusivamente para acesso do
> Internet Banking. Se isso não for uma opção no seu cenário, talvez instalar
> o Postgres em uma VM resolveria.

Não faria mais sentido isolar o culpado?


-- 
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

Re: [pgbr-geral] Res: Re: Res: Re: Postgres x GBuster ou Sistemas Bancos

[Guimarães Faria Corcete DUTRA , Leandro]

Por favor evite mensagens formatadas (HTML ), prefira texto simples
(puro).  E corta o texto a que não estás respondendo.


2016-04-07 17:38 GMT-03:00 fors...@forsell.com.br :
>
> E que de uns 50 locais que temos o postgres instalado, trava em uns 10 
> lugares, todos eles tem o sistema de banco rodando, os que não tem sistema de 
> banco instalado nunca teve o serviço parado.

Como já disse, correlação não implica causação.


> Como a ocorrência é relativamente grande (10 em 50), achei que seria comum a 
> mais gente.

Você pode esperar para ver se aparece mais alguém, mas acho
improvável.  Melhor investigar a causa, fornecendo as informações que
o Gurgel pediu e eu reforcei.



-- 
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

Re: [pgbr-geral] Res: Re: Postgres x GBuster ou Sistemas Bancos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-07 15:12 GMT-03:00 fors...@forsell.com.br :
>
> > O que estamos apostando até agora é que o gbuster, necessário para
> > acessar bancos é que causa essa parada no serviço.

Mas o que alhos teriam a ver com bugalhos?


> > Já instalamos várias versões do postgres e nada.

Costuma ser assim com tiros no escuro.  O ideal seria primeiro
diagnosticar — o que pode ser bem difícil em sistemas proprietários
como o MS Windows e o próprio gBuster —, depois tentar resolver.  Mas
no caso, você nem sabe ainda se tem algo a ver mesmo com o gBuster;
correlação não é causação.


> >Se você nos passar as linhas de log do PostgreSQL que mostram o que
> >ocorre, eventuais logs de sistema também ajudam (saída do comando dmesg,
> >por exemplo), assim como a versão do PostgreSQL (exata com os três
> >números) e do seu sistema operacional.
>
> 2016-03-07 20:19:12 BRT WARNING:  worker took too long to start; canceled
> 2016-03-07 20:20:13 BRT WARNING:  worker took too long to start; canceled
> 2016-03-07 20:21:14 BRT WARNING:  worker took too long to start; canceled
> 2016-03-07 20:22:14 BRT WARNING:  worker took too long to start; canceled
> 2016-03-07 21:35:38 BRT WARNING:  worker took too long to start; canceled

Isso estava em que log?  Veja que o Gurgel pedidu dois, o do PosgreSQL
e o do sistema (dmesg, p. ex.).


> Windows 10

64 bits?  Nem sei se MS Windows 10 ainda tem 32 bits…


> Postgres 9.5.1

Instalado como, a partir de que pacotes?


> mas já tentamos instalando outras 3 versões do postgres

Quais?



-- 
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

Re: [pgbr-geral] pg_activity em Amazon RDS

[Guimarães Faria Corcete DUTRA , Leandro]

2016-04-01 12:55 GMT-03:00 Mario Moreira :
> Boa tarde a todos. Como faço, ou o que devo fazer realmente para não receber
> mais NENHUM email dessa Comunidade, pois já realizei os procedimentos de
> desinscrição apenas 11 vezes.

E cadê o relato de erro?  Como no PostgreSQL em si, é um procedimento
técnico: até que passo você chegou, qual foi a última mensagem do
processo que recebeu…


> A Comunidade POSTGRESQL é de uma maestria
> enorme e ajuda muita gente e muitas empresas, agradeço muito todo
> ensinamento compartilhado mas não desejo mais receber emails dessa
> Comunidade, então Leandro Dutra, Rodrigo Horj e outros administradores por
> favor retirem meu email da lista, obrigado.

Sinto decepcionar mas não sou administrador… nem sei quem são, hoje.


-- 
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

Re: [pgbr-geral] Views !

[Guimarães Faria Corcete DUTRA , Leandro]

Por favor prefira texto simples (puro, não formatado, não HTML ou RTF ou ETF).


2016-03-29 15:06 GMT-03:00 Agape World Informática Ltda
:
>
> Alguem sabe dizer se tem como criar indices em views.

Que sentido isso faria, visto que uma visão não tem dados?


> Outra coisa criei uma view , só o select na view é mais lento que o próprio 
> select direto no sql.

Cadê as informações?  Definições de todos os objetos envolvidos,
consultas e planos de execução?



-- 
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

Re: [pgbr-geral] Sincronismo de bases

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-21 10:11 GMT-03:00 Pedro B. Alves :
>
> Preciso sincronizar os dados com a Matriz e da matriz enviar dados para as
> filiais (como produtos novos; alterações de preços, etc.)
>
> Como eles não tem IP Fixo, vou contratar um cloud.

Se o sistema será remoto, por que não ter uma única base de dados,
separando apenas esquemas no máximo?

Agora, se precisar mesmo fazer sincronia entre bases, creio que coisas
como o Bucardo, em que você pode sincronizar determinados objetos,
possam ser mais adequadas.


-- 
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

Re: [pgbr-geral] Um favor

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-16 10:22 GMT-03:00 Saraiva Silva :
> Ocorre que não tenho o pgModeler instalado e não queria ter todo o trabalho
> de, instalar o Qt, compilar o pgModeler, só para poder abrir o arquivo e
> gerar o script.

Qual teu sistema, não tem pacotes?


-- 
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

Re: [pgbr-geral] Um favor

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-16 10:37 GMT-03:00 Saraiva Silva :
> Ubuntu..
> Não, não tem pacotes.

https://google.com./search?q=pgmodeler+deb



> O pgModeler é um software opensource mas o auto cobra
> uma valor para fornecer binários compilados.

Mas ele não pode impedir a criação dos pacotes.



-- 
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

Re: [pgbr-geral] Um favor

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-16 10:46 GMT-03:00 Saraiva Silva :
> Pois é, pior que tem mesmo, e nos repos oficiais.
> Confesso que dessa vez não procurei, pois eu eu havia procurado a algum
> tempo atrás e não achei.
> Grato

De nada!



-- 
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

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-09 17:38 GMT-03:00 Shander Lyrio :
>
> Em 9 de março de 2016 10:36, Flavio Henrique Araque Gurgel
>  escreveu:
>>>
>> Desculpe, não havia JDBC na pergunta original do colega, ele usa Delphi.
>> Não tenho parâmetros de comparação JDBC/libpq, mesmo se eu use ambos todos
>> os dias.
>
> Legal, ele usa Delphi, mas você falou de REST certo?

Não, foi alguém mais, o Gurgel só respondeu.  Leia as mensagens
anteriores antes de cantar de galo.


> ORM não faz parte do mundo dos bancos de dados

Por isso mesmo está desacreditado.  Porque é uma solução porca de
programadores que nunca entenderam modelos de dados.


> ORM faz parte do mundo dos
> aplicativos que utilizam banco de dados relacionais.

Não, que usam bases de dados SQL.  Relacional de verdade nunca teria
precisado de ORM.  Nem SQL, mas com relacional a ‘necessidade’ seria
ainda mais obviamente absurda.



> Se ORM fosse
> desacreditada, então não teríamos 100% dos projetos utilizam ORM hoje

Não temos, ainda bem.  Informe-se melhor.


> Talvez você não saiba, mas qualquer ORM aceita consultas sql nativas do
> banco de dados, não precisa ser utilizado a linguagem do ORM

E aí ele se torna contraproducente, peso morto.


> De qualquer forma, não estou aqui indicando REST e ORM para todo mundo, só
> acho que não adianta ficar fazendo bulling sem conhecer as ferramentas.

Posso te garantir que o Gurgel conhece-as, bem melhor que tu.

Pesquise também SQL Alchemy.


-- 
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

Re: [pgbr-geral] :: Ferramenta de Modelagem Free ::

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-09 15:28 GMT-03:00 Vinícius Aquino do Vale :
>
> Eu tenho usado o pgModeler.
> Ele é pago (U$8,50), mas o código fonte é open
> (https://github.com/pgmodeler/pgmodeler/releases), basta compilar é usar.

Ou seja, é livre mas alguém cobra por binários?


> Atualmente ele não faz versionamento, mas isso é facilmente resolvido usando
> o próprio versionamento do git.

Ou seja, ele não precisa fazer.  Filosofia Unix, perfeito.


-- 
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

Re: [pgbr-geral] :: Ferramenta de Modelagem Free ::

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-09 13:55 GMT-03:00 Alexsandro Haag :
> Em 09/03/2016 13:48, Wagner Vieira Furno - Lobotech escreveu:
>>
>> Qual ferramenta de modelagem free podemos utilizar para postgresql no
>> momento ?
>
> SQL Power Architect - http://www.sqlpower.ca/page/architect_download_os

A consulta original ficou ambígua —/free/ pode querer dizer livre ou
gratuito—, então pergunto se é gratuito apenas ou também livre…


-- 
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

Re: [pgbr-geral] :: Ferramenta de Modelagem Free ::

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-09 13:48 GMT-03:00 Wagner Vieira Furno - Lobotech
:
>
> Qual ferramenta de modelagem free podemos utilizar para postgresql no momento 
> ?

Há uma variedade enorme.  Meu preferido é código SQL sob controle de
versão e uso pesado e consistente de DOMAINs, com diagramas gerados
por ferramentas como Schema Spy, pg_AutoDoc, SQL::Fairy.

Depende também de requisitos.  Se é apenas para PostgreSQL, fica mais
fácil fazer o que prefiro.  Se tenho de manter o mesmo modelo, ou
mesmo dicionário de dados para outros SGBDs também, que geralmente não
têm DOMAINs e outras facilidades do padrão ISO SQL, aí acaba-se
precisando de ferramentas, como o TOra (só um exemplo, creio que está
ultrapassada).

Os colegas saberão dar muitos outros exemplos.


-- 
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

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-08 10:53 GMT-03:00 Fabrízio de Royes Mello :
>
> Pq? O payload do REST é maior que da libpq...

Fabrízio, poderia explicar-nos o que constituiria a tal ‘carga paga’
de cada uma?



-- 
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

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-07 9:02 GMT-03:00  :
>
> Nos meus testes comparando MySQL com Postgres em acesso remoto a mesma
> estrutura de dados e indices o MySQL fica um pouco mais rapido, mas nada que
> justifique uma migração, eu ainda prefiro o Postgres pela robustes.

Esses testes não suportam uma generalização de que o MySQL seja mais
rápido que o PostgreSQL em acesso remoto.  Há muitas variáveis a
considerar.  Mesmo para a situação específica que você testou,
precisaria comparar a diferença entre o mesmo trabalho em acesso
remoto ou local.


> Olha, eu uso Delphi a muitos anos e gosto muito, mas quando se fala em
> acesso a base de dados remoto pra trabalhos pesados, aiii... que desespero,
> corro logo pra uma linguagem mais apropriada. no meu caso PHP.

Creio que seria importante diferenciar a linguagem (Object Pascal) do
ambiente de desenvolvimento, o Delphi.  A linguagem não morre; o
Lazarus está aí para isso.  Mas o futuro do Delphi é cada dia mais
irrelevante.


-- 
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

Re: [pgbr-geral] Dúvida com modelagem de Controle de Documentos Entregues e com consulta SQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-03 15:40 GMT-03:00 Andre Cavalcante <andre.d.cavalca...@gmail.com>:
>
> 2016-03-02 9:52 GMT-04:00 Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org>:
>>
>> 2016-03-02 9:13 GMT-03:00 Andre Cavalcante <andre.d.cavalca...@gmail.com>:
>> > Aprendiz
>> > ---
>> > id serial
>> > matricula varchar
>> > nome varchar
>>
>> Cada um é uma chave?  Ou a chave são os dois atributos?
>
> id é uma chave primária porque gerado automaticamente pelo banco - é só o id
> do objeto

Certo.  Só lembre que uma chave dessas não cumpre a principal função
de uma chave, que é a de garantir unicidade, nem a de documentar o
modelo (motivo pelo qual perguntei por chaves naturais).

Falando sobre documentação, evite usar simplesmente id como nome de
atributo.  Se não tiver jeito de declarar uma chave natural como
primária (geralmente tem), ao menos dê ao atributo um nome único e
consistente em toda a base, por exemplo (no caso) id_aprendiz.


> matricula é uma chave candidata (unique no banco)
> nome + nomePai + nomeMae é outra chave candidata (unique no banco)
>
> Mas note que isso é apenas para mater o banco estável e com integridade
> relacional. As verificações mesmo são feitas no modelo OO.

Cuidado.  Além de não funcionar na manipulação direta do banco por
usuários ou outros aplicativos, pode levar a relaxar nas verificações
de integridades no banco (que são muito mais que as referenciais), e
sobretudo a não pensar no modelo em si.


> Pensei nisso também, mas como tudo tem um id

Isso normalmente é um mau sinal.


> e a como parte da chave
> candidata em questão é uma data, deixei assim.

Qual o problema de ser data?


> Aí é que está, não tem tanta regra de negócio assim associado. É
> simplesmente um documento que é anexado a um item de histórico. Podem ser
> quantos o operador quiser (e.g. scanner .jpg de RG, CPF ou outro doc). É só
> um repositório para cada item, daí a FK com id de ItemHistorico

Hm, acho que entendi.  Na verdade, se o usuário pode anexar o mesmo
documento várias vezes, caberia um contador, caso em que passa a haver
chave candidata; ou então identificador de instância (por exemplo,
ordem em que foi anexado), caso em que volta a haver chave candidata.
Sempre há chave candidata, a gente é que nem sempre pensa o suficiente
— ou decide deixar o modelo frágil por ser relativamente pouco
importante, mas aí se paga mais tarde com inconsistências internas ou
externas (do banco consigo mesmo ou com a realidade.


> 2. No modelo proposto, como fazer a SQL que retorne todos o documentos
> entregues por um aprendiz?

Não entendi qual o problema, porque não fazer uma junção entre as relações?

Você chegou a tentar e não conseguiu?  Até onde chegou, e qual o
resultado obtido?

Talvez facilite usar o pg_autodoc, o SchemaSpy ou o SQL::Fairy para
poder enxergar o modelo, pode ser que o uso de ids esteja atrapalhando
o entendimento.  Acontece mesmo com modelos que a gente mesmo criou.



-- 
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

Re: [pgbr-geral] Dúvida com modelagem de Controle de Documentos Entregues e com consulta SQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-02 9:13 GMT-03:00 Andre Cavalcante :
> Aprendiz
> ---
> id serial
> matricula varchar
> nome varchar

Cada um é uma chave?  Ou a chave são os dois atributos?


> ItemHistorico
> --
> id serial   {PK - cada item tem um número que o identifica unicamente. A
> chave candidata seria dahoraEvento+idAprendiz, obviamente por se tratar de
> um evento discreto no tempo}

Com uma chave natural de apenas dois atributos, eu pensaria seriamente
em simplificar o modelo eliminando a chave artificial.


> Anexo
> 
> id serial {PK - cada anexo tem um id, sem grandes problemas aqui. Não há
> chave candidata (posso colocar até o mesmo arquivo várias vezes, mas o
> sistema não precisa verificar isso, cabendo ao operador saber o que está
> fazendo}

Isso nunca dá certo.  Mesmo que desse operacionalmente, indica um
problema mais grave de entendimento de modelo e de negócio.

De qualquer maneira, tens outras questões específicas sobre teu modelo
proposto?  Ou o que queres são comentários de base como os que fiz até
agora.


-- 
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

Re: [pgbr-geral] BRT LOG: could not receive data from client: Unknown winsock error 10061

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-22 11:49 GMT-03:00 José Mello Júnior :
> Versão 8.4, Windows Server 2012
>
> Esse erro no log se trata de algum bloqueio?

Demorei a entender que se referia à linha de assunto.


-- 
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

Re: [pgbr-geral] Melhorias da versão 8.1 para versão 9.5

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-18 9:24 GMT-02:00 Marco Aurelio :
>
> É o seguinte, tenho alguns servidores legados (bem legados mesmo, rsrsrs)
> que estão ainda com a versão 8.1 do postgresql, e estou precisando convencer
> a direção a migrar para a versão corrente 9.5, sei que tem os "whats new" de
> cada release, e sei que o principal motivo é que o postgresql não dá suporte
> mais pra esta versão, mas gostaria de compilar as principais novidades e
> melhorias em relação a versão 8 para juntar num doc para convencer o
> pessoal.

Pegue cada nota de versão principal (segundo número: 8.2, 8.3…), pince
entre as principais mudanças a mais relevante, e liste,
preferencialmente com os URIs apontando para o documento traduzido.

Mas não gaste muito tempo com isso, o principal argumento é mesmo a
falta de suporte.  Uma direção que precise de convencimento quanto a
isso está assumindo um risco irrazoável.

Lembre-se que, como se pularão muitas versões, pode haver necessidade
de alteração de código-fonte das aplicações, além da migração dos
dados em si.  Especificamente, lembro que muita gente tropeçou na
falta de conversão automática de tipos.  Teste exaustivamente antes de
migrar a produção, preferencialmente num sistema dedicado para isso,
para que seus ambientes normais de teste não fiquem indisponíveis para
casos emergenciais de produção.


-- 
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

Re: [pgbr-geral] Alta Disponibilidade - PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-16 10:41 GMT-02:00 Marcio Junior Vieira :
>
> Trafego de 300Mbites/segundo

Bits ou /bytes/?  Lembrando que um /byte/ são oito bits.


> Estou me quase decidindo por  usar o BRD
> http://2ndquadrant.com/en-us/resources/bdr/bdr-performance/

Se não me falha a memória, houve discussão disso já há vários anos
nesta lista ou nalguma de suas antecessoras.  Já pesquisaste nos
arquivos da lista?



-- 
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

Re: [pgbr-geral] Omitir Conext em raise exception

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-15 17:35 GMT-02:00 Carlos Antônio Pereira (VidaUTI)
:
>
> Estou tentando omitir o elemento CONTEXT de uma exception utilizando set
> VERBOSITY terse mas não funciona.

O que isso quer dizer?  Nada acontece, ou qual o comportamento?


-- 
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

Re: [pgbr-geral] Alta Disponibilidade - PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-15 16:59 GMT-02:00 Marcio Junior Vieira :
> Em 15.02.2016 16:42, Guimarães Faria Corcete DUTRA escreveu:
>> 300 Mb ou MB?  Por segundo, minuto, hora ou o quê?
>
> Por Segundo

Megabytes ou bits?


>> Márcio, eu acho que faltam ainda informações para poder dar respostas
>> inteligentes.  Por exemplo, que estrutura de particionamento é essa?
>
> particionamento de algumas tabela por dia exemplo "minhatabela_01012016"  e
> tenho algumas mensais minhatabela_012016 todas via procedure! cada tabela
> destes tem uns 900milhões de registros.

E qual o ritmo de mudança dessa tabelas?  Principalmente em pico e concorrência?


>> E que tipo de configuração de equipamento e SO você tem, com que
>> níveis de carga atuais?
>
> VMs em Blade com 48RAM  e 16 processadores em Linux RedHat teremos mais nós
> similares.

Quantas VMs?  Quais os níveis de carga?  Onde estão os gargalos?


-- 
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

Re: [pgbr-geral] Alta Disponibilidade - PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-15 16:03 GMT-02:00 Marcio Junior Vieira :
>
> São em torno de 12.000 conexões simultaneas que estou gerenciando com 
> pgbouncer (funciona bem) e um tráfego de dados de 300MG/ constante pela rede 
> entre aplicação e Database!

300 Mb ou MB?  Por segundo, minuto, hora ou o quê?

Márcio, eu acho que faltam ainda informações para poder dar respostas
inteligentes.  Por exemplo, que estrutura de particionamento é essa?
E que tipo de configuração de equipamento e SO você tem, com que
níveis de carga atuais?


-- 
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

Re: [pgbr-geral] Inteligência do postgresql ao fazer update

[Guimarães Faria Corcete DUTRA , Leandro]

2016-02-10 9:26 GMT-02:00 Flavio Henrique Araque Gurgel :
> Uma solução para o colega da pergunta original é de fazer várias tabelas com
> menos colunas. Neste caso, a função vai fazer UPDATE somente nas tabelas que
> tiveram colunas alteradas por exemplo. Claro que isso tem um custo para
> fazer junções depois, mas aí cada caso precisa ser analisado.

Incidentalmente, esse é um dos benefícios da normalização.  Também
ajuda a diminuir disputa por recursos (E/S, travamento de objetos), e
torna o modelo e sua operação mais fácil de compreender, além de
revelar muito sobre tanto dados quanto aplicações.  Geralmente
eventuais perdas com junções são mais que compensadas pelos
benefícios.


-- 
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

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

[Guimarães Faria Corcete DUTRA , Leandro]

2016-01-19 17:44 GMT-02:00 Mauro Sérgio :
>> O SchemaSpy é bacana, pena que o código parou no tempo em 2010. Mas ainda
>> asim ele gera diagramas super úteis pra navegar visualmente no esquema.
>
> O SchemaCrawler [1] é uma alternativa, o projeto recebe atualizações
> com frequência.

Parece muito interessante ,
obrigadíssimo!


-- 
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

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

[Guimarães Faria Corcete DUTRA , Leandro]

2016-01-18 19:57 GMT-02:00 Tiago José Adami :
>
> 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.

Isso é otimização precoce.  Geralmente não é o caso; geralmente, o
tempo de resposta e a distribuição ficam melhores com as regras
declaradas no banco; a segunda melhor situação é quando não dá para
declarar tudo, e precisa também usar o famoso ‘código procedural’, mas
ainda no banco.

Inclusive, é muito mais ágil alterar uma regra declarada, ou ao menos
centralizada, no banco, que espalhada por outras camadas — ceteris
paribus.  Claro que há aquelas situações em que se tem medo ou
burocracia para mexer no banco, mas aí é um problema organizacional e
circunstancial, não técnico e essencial.

Uma abordagem interessante foi a do Alphora Dataphor, que parece que
estagnou sem chegar a ser portado para fora do MS Windows, mas que
permitia declarar tudo na base e distribuir as declarações da base em
outras camadas quando necessário sem precisar reprogramar.


-- 
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

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

Re: [pgbr-geral] Ajuda para montar ambiente com servidores multi-master

[Guimarães Faria Corcete DUTRA , Leandro]

2015-12-03 14:42 GMT-02:00 Mauricio Tavares :
>
> Quanto falei "ganbiarra" (note as aspas) não foi para desmerecer os esforços
> da comunidade em criar melhorias para um banco que já fornece muitos
> recursos avançados. (muitos já evidenciados aqui na lista).  Mas foi para
> evidenciar que tais modificações foram implementadas para suprir uma
> necessidade que outros bancos de dados já fornecem nativamente.

Mas então o termo não é esse.  Colocar entre aspas não nos diz
exatamente o que você quis dizer.

E outra: quando o PostgreSQL implementa algo, não vende para casos
inadequados, e oferece alta qualidade.  Só uma comparação: leia o
artigo ‘You don’t need RAC’ (ou algo assim) da Oak table network, e
compare a lista de defeitos (/bugs/) conhecidos do PostgreSQL com a de
outros SGBDs, livres ou proprietários, SQL ou prerrelacionais (‘NoSQL’
).


> Uma coisa que me chamou a atenção no postgres XC, foi a versão do Postgres é
> a 9.1. uma versão relativamente antiga visto que já estamos na versão 9.4.
> Ressalto que, confio na versão 9.1.

E se você ler o que a equipe do XC publicou a respeito, ou mesmo
outros projetos com abordagens parecidas, como a do PostGIS (em menor
grau), verás que o atraso é proposital, faz parte do processo.

De novo, é uma necessidade de nicho, e um grande aumento de
complexidade num projeto que hoje tem zero defeitos conhecidos.
Devagar com o andor… que deste lado do paraíso funcional, o santo é de
barro.


> O órgão onde trabalho possui muitos servidores (uns virtuais, outros
> físicos) com bases de dados pequenas. Visando um melhor aproveitamentos dos
> recursos disponíveis na infraestrutura, foi cogitado em montar uma  "Base
> Única de Dados", e agrupar todas estas pequenas bases de dados nesta base
> única.  Inicialmente seriam entre 3 a 5 nós de servidores. É por isto a
> necessidade do multi-master.

Multimestre (BD distribuído) me parece uma solução completamente
equivocada, pelo menos tomando por base essa descrição para lá de
sucinta.

Vejamos.  Hoje são bases distintas.  Por que unificá-las implicaria em
ter vários mestres?  Por que não poderia ser de um a cinco mestres com
quantas réplicas forem necessárias?  Porque não podem ser até cinco
bases se comunicando entre si?

Veja que o uso de réplicas tem dois benefícios: além de alta
disponibilidade e recuperação, também podem receber muitas consultas
para aliviar os servidores principais.


> Bem, o cenário é este E evidentemente estou aberto a sugestões  de uma
> arquitetura diferente a multi-master. Entretanto, precisarei de apoio dos
> Srs. para ter argumentos técnicos para discutir dais propostas com a equipe
> de infra, visto que é ela que está batendo o pé em ter tal ambiente
> multi-serve.

O principal argumento é a falta de necessidade.  Pelo menos em sua
mensagem, não encontrei argumentos demonstrando a necessidade de BD
distribuída, muito menos demonstração da consideração (e descarte) de
alternativas.


-- 
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

Re: [pgbr-geral] Ajuda para montar ambiente com servidores multi-master

[Guimarães Faria Corcete DUTRA , Leandro]

Por favor evite responder em HTML, tornou confusa a mensagem.  Também
apague as partes irrelevantas da mensagem a que responde, por favor.


2015-12-03 15:28 GMT-02:00 Mauricio Tavares :
>
>> Por que unificá-las implicaria em ter vários mestres?
> O argumento que o responsável da infra deu, foi que caso um dos servidores
> caia, seria fácil redirecionar as aplicações para outro servidor.

Isso é muito mais verdade com réplicas (inerentemente mais simples)
que com um BD distribuído.

Veja, num BD distribuído, uma base pode perder comunicação com outra
mas continuar aceitando transações.  Tem de haver um mecanismo, que
não é facilmente automatizável, para numa perda de comunicação decidir
quais bases continua e quais param.  Na prática, tem de haver um
diretor, automático ou humano, e preferencialmente humano.


> Mas aí, tenho uma pergunta, o pgpool poderia fazer o papel do balanceador?

Não é minha praia, mas isso é constantemente discutido nesta lista.
Faça uma busca simples nos arquivos.


>> Por que não poderia ser de um a cinco mestres com quantas réplicas forem
>> necessárias?
> Poderia ser desta forma, e ter para cada servidor mestre, um slave
> replicando.

Ou mais.


> Entretanto, promover o slave para o master, envolveria parar,
> reconfigurar para master e reiniciá-lo. Estou correto???

Você já pesquisou?  Isso é constantemente discutido aqui.


> Porque não podem ser até cinco bases se comunicando entre si?
> Até onde sei, cinco base se comunicando entre sí, seria 1 master e 4 slave.
> Correto?

Não. Se hoje você tem mais de cinco bases independentes, é muito mais
simples mantê-las independentes, mesmo que como esquemas ou bases
dentro de até cinco servidores físicos.  Assim as aplicações não
precisam mudar num primeiro momento; depois de consolidados os
servidores, pode-se começar a unificar logicamente as bases, com
conseqüentes mudanças de aplicação.

Do jeito que você está falando, parece que o seu responsável de infra
não sabe do que está falando: parece que confundiu unificar servidores
(trivial) com unificar bases (que não é uma questão primariamente de
infra).


> Ou tem outra forma de implementar esta comunicação entre elas?

Várias!

Mas a primeira pergunta é, que comunicação é realmente necessária?  O
seu cenário parece ser uma simples consolidação de servidores,
presumivelmente aproveitando servidores tornados disponívels pela
consolidação para criar réplicas.


> Temos alguns sistemas que usam um servidor master para as transações e um
> servidor slave só para as atividades de relatórios e BI.

Exato.


-- 
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

Re: [pgbr-geral] Ajuda para montar ambiente com servidores multi-master

[Guimarães Faria Corcete DUTRA , Leandro]

2015-12-03 13:49 GMT-02:00 Mauricio Tavares :
> Pois é  eu notei que tanto o Postgres-XC como o XL foram apenas uma
> "gambiarra" para contornar a ausência deste recurso.

Não, Maurício.  O XC e o XL são bifurcações devidas ao porte das
alterações necessários ser demasiado para pronta incorporação ao
projeto principal.  A idéia é amadurecer a implementação para então
planejar a incorporação, mas não há gambiarra alguma.  Os japoneses
que estão fazendo isso são muito sérios e metódicos, conversei com o
líder do projeto num PgBr d’antanho e fiquei muito bem impressionado
com o conhecimento e equilíbrio dele, muito longo do mundo de /hype/
que costumamos ver na Informática.


> Estou muito resistente em colocar tais opções em produção e depois ter dor
> de cabeça e noites sem sono.

E para quê existem pilotos e testes de carga?

Isso dito, a solução mais simples é sempre a melhor.  Antes de partir
para algo inerentemente mais complexo, sempre é bom limar coisas que
possam gerar falsas necessidades; no seu caso, você não explicou por
que quer um BD distribuído.  Por exemplo, pode ser que sua necessidade
de distribuição seja melhor atendida combinando replicação de objetos
(tipo Bucardo) com uma modelagem de dados específica; se for
confiabilidade, com replicação simples, ‘nativa’; se for desempenho,
limando ORM em favor de acesso nativo, e por aí vai.


-- 
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

Re: [pgbr-geral] Ofuscador

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-30 18:06 GMT-02:00 Vinícius Aquino do Vale :
>
> Estou precisando atualizar a base de homologação com dados de produção,
> porém preciso ofuscar alguns dados por serem confidenciais.
>
> Ex: campo CPF, CNPJ, CEP e etc.
>
> Alguém conhece ou já usou algum ofuscador que faça isso para postgresql?

Você quer um gerador de dados aleatórios?  Ou entendi errado?


-- 
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

Re: [pgbr-geral] USUÁRIO PARA BACKUP

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-26 8:51 GMT-02:00 Flavio Henrique Araque Gurgel :
>> Le 25 novembre 2015 20:28:32 GMT-02:00, Sebastian Webber
>>  a écrit :
>>>
>>> Desculpem o top posting. Estou no celular e fica difícil formatar o
>>> texto.
>>
>> K-9.
>
> Dutra se rendeu ao Android?

Faz tempo, acho que já estou no terceiro Google Android/Linux.

Não consegui nenhum celular GNU/Linux depois do Nokia N900, que aliás
era mal resolvido.

Mas a questão aí não é ser Android, é permitir escrever mensagens
corretamente, em texto simples e após os textos a que se responde.


-- 
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

Re: [pgbr-geral] USUÁRIO PARA BACKUP

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-26 9:25 GMT-02:00 Sebastian Webber :
>
> 2015-11-25 21:21 GMT-02:00 Leandro Guimarães Faria Corcete DUTRA
> :
>> Le 25 novembre 2015 20:28:32 GMT-02:00, Sebastian Webber
>>  a écrit :
>> >Desculpem o top posting. Estou no celular e fica difícil formatar o
>> >texto.
>>
>> K-9.
>
> Além da possível referencia ao cão policial, eu não entendi o comentário.

Agora eu é que fiquei curioso, conheço como o cão do doutor Who.


> Estou mais curioso do que incomodado. O que queres dizer com isso?

Um bom cliente de correio eletrônico para dispositivos limitados, que
permite responder mensagens corretamente e é extremamente flexível.


-- 
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

Re: [pgbr-geral] Backup

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-24 8:43 GMT-02:00 Antonio Cesar :
> Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar para
> uma maquina windows, alguem tem algum exemplo?

Use o cygwin.


-- 
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

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-23 17:24 GMT-02:00 Osvaldo Kussama :
> Não sei se existe CPF 0-XX mas o CNPJ do Banco de Brasil é:
> 00.000.000/0001-91

Boa!  ;-)


> Que, pelas suas considerações, seria um domínio de 0 a 
> acrescido da filial, de 0001 a , e dos DV.

Exato.  Mais uma vez, imagino que não haja CNPJ 00.000.000/, ou filiais /.


-- 
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

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-23 15:58 GMT-02:00 Sebastian Webber :
>
> Meu caro Dutra, segundo a doc[1], dá pra dizer que:
>
> CREATE DOMAIN creates a new domain. A domain is essentially a data type with
> optional constraints (restrictions on the allowed set of values) ...

Então, mais ou menos… esse é um ponto em que nossa documentação comete
um erro conceitual grosseiro.


> Domains are useful for abstracting common constraints on fields into a
> single location for maintenance.

Perfeito, mas não apenas.

O DOMAIN do SQL, que o PostgreSQL segue, não é domínio de verdade.
Creio que já (tentei) explicar isso aqui antes, mas como é um dos meus
assuntos favoritos, tentarei de novo:

Um domínio é uma lista de valores — conceitualmente, porque podem ser
valores contínuos (não discretos), caso em que a lista não pode ser
realizada; idem para domínios infinitos.  Um tipo de dados é um
domínio e seus operadores.

Por exemplo, no caso ‘em tela’ (jargão aqui de Brasília), um CPF é um
número de até onze caracteres, ou precisamente onze se o precedermos
de zeros.  Até onde eu saiba; perdoem alguma imprecisão no exemplo.  O
domínio CPF é constituído de todos os números de CPF válidos.  Como
apenas os nove números excluindo os dois dígitos verificadores à
direita são relevantes para gerar a lista, podemos dizer que o
domínio, a princípio, seria de 1 a 999.999.999, concatenados com os
respectivos dígitos verificadores.  No caso, suponho que 0 seja um
caso especial, ou seja, que não haja um CPF 0-XX onde XX seriam os DVs
correspondentes a 0.

Já o tipo de dados seriam os operadores correspondentes.  Não consigo
imaginar, de bate-pronto, algum operador que não seja o de identidade
(comparação para ver se é igual ou diferente); por exemplo, não me
parece fazer sentido querer concatenar, cortar, somar, subtrair,
multiplicar, dividir, comparar se maior ou menos   Talvez
operadores para extrair os dígitos significativos (os nove excetuando
os DVs) e os dígitos verificadores.

O interessante a reter é que não faz sentido operar num determinado
domínio com operadores que não correspondam ao tipo.  Portanto, por
definição, uma definição de domínio tem de excluir operações de outros
tipos (por exemplo, concatenar ou multiplicar CPFs), ou que envolvam
outros domínios sem que sejam operações especificamente previstas para
o domínio em questão e outro domínio qualuqer (por exemplo, concatenar
um CPF com um CNPJ, ou multiplicar um CPF por um CNPJ).

Até onde já li e testei, um DOMAIN SQL não impede isso.  Teste; deve
ser possível CREATE TABLE cpf (cpf AS cpf);  com esse DOMAIN, e fazer
um SELECT cpf * 2 FROM cpf;, o que não seria possível com um domínio
de verdade.

Aproveitando para bater noutra tecla que me é cara, é por causa desse
tipo de problema de confusão conceitual (embora não desse problema
específico) que o SQL não é relacional: para começo de conversa, uma
tabela SQL não necessariamente é uma relação (que precisa de ao menos
uma chave natural), mas pode ser um saco (sem chave natural, ou seja,
não é um conjunto).


> For example, several tables might contain
> email address columns, all requiring the same CHECK constraint to verify the
> address syntax. Define a domain rather than setting up each table's
> constraint individually.

Ou seja, é útil mesmo sem ser um domínio: é um atalho para declarar
uma restrição de validação.


> Chamamos isso de empate técnico? :D
>
> [1] http://www.postgresql.org/docs/current/static/sql-createdomain.htm

Posso dizer que não é uma disputa, portanto não faz sentido falar em
empate?  ;-)


-- 
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

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-23 14:26 GMT-02:00 Sebastian Webber :
>
> Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de
> validações feito pelo guedes ele já implementa o tipo de dados cpf. e com
> isso já facilita a validação do mesmo como numeric.

Sendo um pouco chato, mas no interesse da precisão, até onde entendi o
módulo — muito útil — implementa um DOMAIN SQL, o que não é um domínio
(!), portanto não é um tipo de dado; mas é a coisa mais parecida, e
útil, com um domínio de verdade.


-- 
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

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-22 22:47 GMT-02:00 Gerdan Rezende dos Santos :
> Cpf com zero?? O meu comeca assim 001... Te respondi???

Não.  Perguntei ‘que têm’, quer dizer, que diferença faz (dado tudo
que já conversamos até aqui).


> Transformação no banco custa, banco e pra armazanar e consultar

Armazenamento e consulta também custam.  A avaliar o que custa mais.
E outra: geralmente o gargalo num sistema é E/S, não processamento.
Portanto, geralmente vale a pena economizar armazenamento se o custo
em processamento não for exagerado.  E não parece ser.


> quer deixar bonito bota na aplicacao

A aplicação pode estar na base de dados também.  Aliás, é o melhor
lugar para ficar, garantindo consistência em qualquer uso, por
qualquer programa aplicativo, e compartilhando recursos com o resto do
servidor.


> se a mascara for executada no cliente melhor ainda...

Pior.  Quanto mais perto dos dados, melhor, tanto em velocidade
(latência, compartilhamento de recursos) quanto em consistência.


> Pq usar char?? Poderia comecar te dizendo pra ser ter um padrão no seu
> armazanamento...

Um padrão qualquer é melhor que padrão nenhum.  Mas um padrão
específico não é obviamente mais útil em si mesmo que um padrão
alternativo, sem alguma explicação.


> Ah qto a você me sacanear...

Não sacaneei nada.  Só achei que você seria capaz de contribuir ainda mais.


> Sua preoculpação deveria ser em ajudar ao colega

E foi.


> eu não sou dono da verdade!

Mas escreveu como se achasse ser.


-- 
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

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

Le 21 nov. 2015 18:19, "Gerdan Rezende dos Santos"  a
écrit :
>
> Lembre-se dos cpf que comecam com 0!

Que têm?  É questão de apresentação, não armazenamento.

> Segundo ponto para mim:  o que é mais escasso disco ou processador?
> Depende do volume de acesso quantidade de informação, etc!

Sim, óbvio, e daí?  Não estou sacaneando, só quero saber onde você quer
chegar?

> Costumos usar um char(numero extado) pra guardar este tipo de informacao!

Como já disse, legal compartilhar experiências, mas é melhor ainda dizer as
razões e as conseqüências.

-- 
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

Re: [pgbr-geral] Instalação do Postgres 9.3 no Windows 7 Ultimate

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-19 16:02 GMT-02:00 Ronei Heck :
>
> Pergunto: existe uma maneira de instalar o postgres de forma
> automatizada/silenciosa?

Volta e meia esse assunto volta à tona aqui, creio que vários colegas
já discorreram a respeito.  Se não achar, procure por ‘PostgreSQL
embedded OR "silent install"’.  Se não me engano, há um instalador
alternativo, tipo Enterprise DB ou algo assim, com essa capacidade, se
não estiver já no oficial.


-- 
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

Re: [pgbr-geral] Instalação do Postgres 9.3 no Windows 7 Ultimate

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-19 14:10 GMT-02:00 Itamar Reis Peixoto :
>
> experimentem o linux, é muito mais facil instalar num centos, fedora ou
> debian do que no M$ window$

Pelo que entendi, o colega não tem opção, está instalando em clientes.
Só não entendi porque instalar o servidor PostgreSQL num cliente MS
Windows.  Imagino uma situação onde ele não saiba de que componentes
um aplicativo precise, ou que não valha a pena fazer uma instalação do
PostgreSQL como sistema embutido (/embedded system/).


-- 
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

Re: [pgbr-geral] Instalação do postgres 9.3 em opensuse

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-17 14:00 GMT-02:00 Danilo Silva :
> Particularmente, eu prefiro instalar via repositório

Claro.


> mas no caso do openSuse, não achei nenhum
> repositório para adicionar

O Debian tem repositórios específicos do PostgreSQL, já olhou em
http://postgresql.org/ para ver se não há também para RPM em geral ou
OpenSuSE em particular?

Também olhe se há pelo menos RPMs compatíveis.  Se não houver, não
adiantará muito procurar repositórios.



-- 
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

Re: [pgbr-geral] Instalação do postgres 9.3 em opensuse

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-17 13:41 GMT-02:00 Danilo Silva :
>
> A versão 9.3 do postgres roda no openSuse 11.3 ?

Sim, por que não?


> É possível instalar via repositório? pois não achei nada no google

Apesar de ser raro, às vezes vale mais a pena ir para fontes
específicas de informação.  No caso, o sítio da Novell e
http://postgresql.org/


> o padrão desta versão do openSuse é a versão 8.4.

Creio que isso seja irrelevante.


-- 
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

Re: [pgbr-geral] Permissão

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-17 18:52 GMT-02:00 Raphael Coutinho :
>
>   Mesmo que ele não tenha permissão para fazer nada nos outros esquemas, não 
> é interessante ele conseguir listar essa estrutura.

Não vejo problema, se a estrutura não revelar informações sobre os
outros.  Não é normal querer fazer isso, se a modelagem for
minimamente razoável.

Pesquise o arquivo da lista, isso já foi discutido antes.  Há uma
maneira, se não me falha a memória, mas não é suportada.


-- 
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

Re: [pgbr-geral] Gerar dicionário de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-16 13:41 GMT-02:00 Danilo Silva :
>
> É possível gerarmos um dicionário de dados através das tabelas de catálogos?

Você saberia explicar melhor o que você quereria num dicionário?  Ou
só o básico?


-- 
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

Re: [pgbr-geral] Gerar dicionário de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-16 13:46 GMT-02:00 Flavio Henrique Araque Gurgel :
> Mas eu deixo o Dutra te explicar melhor, ele é o mestre da documentação de
> dados, tipo, já mostrou suas astúcias mundo afora.

Estou enferrujadíssimo, Gurgel… mas creio que minha apresentação ainda
está por aí, disponível, _O elefante arborícola_.

Para resumir, o AutoDoc, o SQL::Fairy e algumas outras ferramentas
geram ótimos diagramas; e podem-se usar ferramentas de programação
literária como o noweb para criar documentos em LaTeX, HTML ou outros
formatos que ao mesmo tempo definem o modelo, o documentam e
incorporam gràficos de alta qualidade, automaticamente gerados.  Exige
certa preparação, mas o resultado é surpreendente.

Só para documentar o que já existe, costuma bastar AutoDoc, SQL::Fairy
ou equivalentes.


-- 
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

Re: [pgbr-geral] Gerar dicionário de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-16 14:27 GMT-02:00 Alexsander Rosa :
>
> Atualmente usamos o SchemaSpy. Usávamos o Autodoc antes.

Pode explicar o que levou a abandonar um e adotar outro, para nosso benefício?


-- 
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

Re: [pgbr-geral] Gerar dicionário de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-16 13:41 GMT-02:00 Danilo Silva :
>
> É possível gerarmos um dicionário de dados através das tabelas de catálogos?

Você saberia explicar melhor o que você quereria num dicionário?  Ou
só o básico?


-- 
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

Re: [pgbr-geral] Gerar dicionário de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-16 16:40 GMT-02:00 Alexsander Rosa :
>
> Não sei se dá pra chamar de ativo, o último release (5.0.0) é de 2010.

Preocupante.  Será que não migrou para alhures?


> Mas funciona. :-)

Bom!

O ideal seria evoluir, até para acompanhar a evolução do SQL.  Mas
esta é uma evolução lenta, e geralmente o que se quer é o básico.


-- 
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

Re: [pgbr-geral] Gerar dicionário de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-16 15:59 GMT-02:00 Alexsander Rosa :
>
> No autodoc são poucos arquivos enormes, a navegação é por hashtags HTML.
> Os diagramas são enormes, com centenas de tabelas vira um emaranhado.

Eu resolvia isso gerando dumps parciais, para o Auto doc gerar vários diagramas.


> No SchemaSpy são vários arquivos, um pra cada tabela, com mais detalhes.
> Tem até um mini-diagrama mostrando os relacionamentos mais próximos.
> E o resultado é interativo, dá para mostrar mais ou menos detalhes.

Legal, muito bom.


> Veja esse exemplo do próprio site deles:
> http://schemaspy.sourceforge.net/sample/tables/book.html

Faz tempo que não vejo um projeto ativo no Source forge.


-- 
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

Re: [pgbr-geral] PostgreSQL + NoSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-11 23:29 GMT-02:00 Bruno Felipe :
>
> Porque estou fazendo um trabalho sobre isso.

Ah, bom… meus pêsames e boa sorte!  Imagino que seja trabalho de escola.


> por que tiro no pé?

Porque, por definição, o NoSQL é apenas um outro nome para
prerrelacional, portanto inferior (a não ser para situações muito, mas
muito específicas mesmo).


> Vou estudar mais o tipo JSonB

Foi só um exemplo, há várias possibilidades no PostgreSQL.  Depende
essencialmente do que você quer armazenar, e como; passar de SQL para
NoSQL é, essencialmente, perder a abstração que o SQL fornece e ter de
escolher prematuramente tanto forma de armazenamento físico quanto
caminho de acesso (que em SQL é decidido dinamicamente pelo planejador
de consultas).

A dica do FDW que o Leonardo César passou talvez possa te ajudar a
entregar esse trabalho.


-- 
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

Re: [pgbr-geral] PostgreSQL + NoSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-12 11:38 GMT-02:00 Flávio Alves Granato :
>
> Único ponto que discordo é a palavra "portanto", mas entendo a preferencia
> dele pelo modelo relacional, acho as ferramentas podem coexistir e serem
> consideradas de primeira linha. Claro que temos umas ferramentas "mais"
> universais que as outras

Antes que isso: o modelo relacional é universal.  A contribuição real
dos NoSQL se restringe a implementações físicas que ainda não tinham
sido incorporadas ao SQL, mas o estão sendo e em grande parte já estão
disponíveis como tipos PostgreSQL.


> como o PostgreSQL caminhando para trabalhar com
> dados JSON muito bem como os famosos NoSQL

Já trabalha com JSon e outros tipos, geralmente melhor que os infames NoSQL.


> A questão da escolha foi a base de dados totalmente desnormalizada e ruim,
> fruto de 20 anos de falta de manutenção corretiva/evolutiva e a necessidade
> de entregar dados mais rapidamente. Utilizamos o Riak por motivos de
> garantias de persistencia de dados em cluster, built-in e a velocidade para
> chave-valor que queríamos. Hoje conseguimos entregar dados para os
> servidores web em 17,3ms e chegando em alguns caso em 2,7ms.

Já olhou o chave-valor do PostgreSQL?


> Fator de não utilizarmos o postgresql para esta função, já que ele dá conta
> perfeitamente, o bloqueio mental que nossos dbas tem pois eles não admitem
> algo que eles julguem pior no ambiente deles, mesmo provando por A + B que é
> melhor e igual em 99,9% das situações do dia a dia e que nos 0,1% em que o
> software proprietário é melhor o negócio pode absorver a "demora" ou
> possível ineficiência do postgresql. Mas meu estoque de paciência para lidar
> com FUD já se acabou a muito tempo.

Aí é triste, não dá para ser feliz…


> Nada contra ao Dutra, somente contra ao uso das palavras "portanto
> inferior", "EU" gostaria que tivesse sido: portanto irmãos ou portanto mais
> antigo... hehehehehehe...

Você só vai entender o porquê da inferioridade quando ler (e entender)
o artigo original do Codd, ou um dos vários resumos do modelo
relacional publicados por exemplo pelo Date.  Como sempre digo, no
Brasil é raro quem ensine modelo relacional; geralmente as pessoas
entendem mal o SQL e acham que esse malentendido sobre o SQL é a
essência do modelo relacional.


-- 
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

Re: [pgbr-geral] PostgreSQL + NoSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-12 12:50 GMT-02:00 Flávio Alves Granato :
>
> Concordo, mas como as escolhas ocorrem em um ponto no tecido do
> espaço-tempo, no momento em que eu estava testando o postgresql com uma
> tabela em que o tipo da coluna era json, faltava alguma coisa para nossas
> queries. Se não me engano, pois já deve ter uns 2 anos estes testes

Isso é bom deixar claro.  Numa área em que as mudanças são tão
constantes, especialmente na evolução do PostgreSQL, embora ainda seja
importante conhecer a história, decisões do passado não
necessariamente se aplicam como referência a decisões presentes.


> Já e por mim utilizaria fácil, mas ouvimos do nosso dba que ele tem 365 x
> 10²³ ceriticações de sql server e que não iria utilizar postgresql em nosso
> ambiente e após isso vários FUDs... logo, ele não conseguiu o mesmo efeito
> contra um conceito que ele não conhece.

Triste!  Alguém assim merecia um pouco de desemprego, com o perdão da
família que ele sustenta com o suor dos vossos rostos…


> Concordo contigo, preciso sair do meu mundinho e ler mais o Codd e reler o
> Date, mesmo sendo um desenvolvedor isso vai me ajudar muito.

Vai firme!


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-10 21:59 GMT-02:00 Fabrízio de Royes Mello <fabri...@timbira.com.br>:
> On 10-11-2015 20:35, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> 2015-11-10 20:32 GMT-02:00 Flavio Henrique Araque Gurgel <fha...@gmail.com>:
>>>
>>> http://www.jooq.org/
>>
>> Tem alternativa livre?
>
> Conforme consta em [1] para bancos "open source" eles tem uma
> alternativa utilizando a "Apache Software License 2.0".
>
> [1] http://www.jooq.org/download/

Falha minha não ter fuçado antes de perguntar.  Nem é alternativa, é o
mesmo sistema sem os acionadores de SGBDs proprietários nem garantia
de suporte (/best effort/ em inglês apenas, o que talvez seja mais que
suficiente).  Um /freemium/ que me parece plenamente aceitável, até me
espanta não usarem a GNU AGPL v3 para esse fim.


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-11 19:18 GMT-02:00 Flavio Henrique Araque Gurgel :
> Freemium é tipo "o núcleo e bibliotecas são livres só que aquela ferramenta
> que faz toda a diferença no dia-a-dia é paga". Não é bem o caso do Jooq, uma
> vez que 100% do código e funcionalidades estão disponíveis em Apache
> License, para os bancos livres suportados, não tendo nada escondido. O
> suporte profissional está disponível para todas as versões inclusive a
> livre.

Pense em quem tem de suportar algum SGBD proprietário, além do livre.
Mas digo não como crítica; sou totalmente a favor de que quem usa
proprietário pague para ajudar o livre.


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-11 19:23 GMT-02:00 Flavio Henrique Araque Gurgel :
>
> Esclareceu minha dúvida sobre seu entendimento, obrigado.

Disponha!  Não que meu entendimento seja de muita valia…


> Mas ainda acho um pouco longe do Freemium que vejo por aí afora, que são
> totalmente inúteis sem pagamento da parte proprietária, o que não é o caso
> do Jooq.

Perfeitamente.

Vejo isso como um contínuo.  Tem o OTRS::ITSM por exemplo, que é
bastante útil sem os módulos proprietários, mas onde a falta deles
chega a ser bastante inconveniente; creio que o OTRS::ITSM é um
meio-termo entre o Jooq e o que você está pensando como /freemium/.


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-10 15:34 GMT-02:00 Luciano Reis :
> Tive a impressão de que a comunidade PostgreSQL tem
> uma certa rejeição à ORM's

Não todos, nem a todos os MORs (Mapeamentos Objeto-Relacionais), nem a
todos os aspectos dos MORs.


> e gostaria de opinião de vocês, procede isso,

Em grande parte.


> DBAs  odeiam ORM's?

De maneira geral, sim.


> da para trabalhar junto?...

Sim, se o MOR for razoável.

Um MOR razoável:

* Não tenta fazer o SQL parecer OO, mas apenas facilita a sintaxe para
a linguagem OO.

* Não transforma um comando MOR em várias ações SQL com conseqüências opacas.

A razão é que OO não se aplica a dados.  O modelo relacional é mais
transparente, mais poderoso, mais lógico, mais conciso que OO no que
se refere a dados.  O Chris(topher) J Date, se não me falha a memória,
tem ao menos um bom artigo a respeito.

Um exemplo de MOR razoável é o SQL Alchemy (Python).

Um exemplo de MOR lixo é o Hibernate (Java).

Mesmo um MOR lixo pode ser usado decentemente, mas torna-se contraprodutivo.

Não sei se há MORs decentes para PHP, espero que haja.  Por um lado, é
uma linguagem tão popular que poderia haver; por outro, é uma
linguagem com tantos problemas conceituais que não tenho muita
esperança que haja.


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-10 17:45 GMT-02:00 Luciano Reis :
> O que eu uso é o Doctrine, agiliza bastante o desenvolvimento, nele você
> escolhe como quer trabalhar, gerando modelo através de classes ou classes
> através de modelos, acho mais coerente as classes obedecerem um modelo.
> O que mais eu posso cuidar para que o uso do ORM com PostgreSQL seja pelo
> menos razoável?

Olha, a página que você enviou diz que ele tem uma linguagem baseada
na do Hibernate.  Isso normalmente significaria problema.  Dê uma
olhada em como o SQL Alchemy (Python) faz, talvez isso te dê alguma
luz.


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-10 20:32 GMT-02:00 Flavio Henrique Araque Gurgel :
>
> Esqueçam ORMs, o mundo evoluiu e está muito melhor.

Obrigado, Flávio!

Estou seriamente pensando em esperar 24 h antes de responder qualquer
coisa, já que o Flávio geralmente vem com respostas melhores que as
minhas…


-- 
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

Re: [pgbr-geral] ORM's

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-10 20:32 GMT-02:00 Flavio Henrique Araque Gurgel :
>
> http://www.jooq.org/

Tem alternativa livre?


-- 
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

Re: [pgbr-geral] pg_log parâmetros de coleta de logs

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-09 11:25 GMT-02:00 Joel Benelli :
>
> Estou desenvolvimento um trabalho em um servidor de testes que tem
> aproximadamente 400 DB referentes a vários sistema.

Parece um número exagerado de bases de dados, a princípio.  Você usa
esquemas?  Já pensou em organizar um número menor de bases, usando
esquemas dentro de cada base?


-- 
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

Re: [pgbr-geral] pg_log parâmetros de coleta de logs

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-09 13:45 GMT-02:00 Joel Benelli :
> De fato Guimarães, bem exagerado, o servidor atende duas equipes de
> desenvolvimento, suporte técnico, e setor de projetos de vário produtos,
> ..., caos ...

Imagino!

Quando vivi algo assim, a gente conseguir controlar um pouco com o uso
judicioso de esquemas, com um sistema de nomenclatura para facilitar.


-- 
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

Re: [pgbr-geral] [off-topic] Only NoSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-05 21:46 GMT-02:00 Vinícius Aquino do Vale :
>
[…]
> MemCached, TitanDB entre outras todas são consideradas noSQL.

Claro que não.  Memcached é apenas um mecanismo para acelerar o acesso
físico a dados, independentemente do modelo, como o nome já indica:
MEMory CACHE Daemon, ou serviço de cache de memória.


> Essas
> aplicações vieram resolver diversos limitações que atualmente assolam o SQL,
> principalmente pela norma ACID.

Mito.  Acid e SQL são ortogonais.


> Existem vários tipo de noSQL:
>   * Hash (Dynamo, Memcached)
>   * Grafos - (TitanDB)
>   * Documentos  (MongoDB, CouchDB)
>   * Multicolunar (HBase, Bitable)

Todos prerrelacionais, reempacotados para a nova ignorância do século XXI.


> Todos eles são schemaless o que não obriga estruturação seguindo algum
> modelo como no caso do relacional. Basicamente vc cria a aplicação e vai
> salvando os dados, depois vc se preocupa  com o que estão salvos.

E aí vêm as limitações.  Leia o artigo do EF Codd.  Ele já aponta
problemas e soluções em, se não me falha a memória, 1969 (mas acho que
a primeira versão pública é de 1971).  Algo como _Large shared data
banks_.


> Situações onde é mais necessário gerar relacionamento

O que é trivial no modelo relacional (embora o nome se refira a
relações matemáticas, que diferem de relacionamentos que são
implementados as restrições de integridade relacional).


> igual na amazon onde
> "clientes que visualizaram isso, também visualizaram aquilo." é muito
> complicado de montar quando tem que ser para vários clientes simultaneamente
> - haja memória - Neste caso um banco de grafos como o TitanDB, seria a
> melhor solução.

Não, foi uma melhor solução para alguns casos muito específicos com a
tecnologia da época.  Muitos desses casos já estão cobertos, com as
vantagens inerentes ao modelo relacional, nas últimas versões do
PostgreSQL, e com muito mais maturidade que qualquer NoSQL.


> É provável que o relacional, nunca seja substituído. Porém, muitas dessas
> ferramentas já estão adicionando partes da ACID em suas soluções. E se
> formos pensar bem, são poucas a empresas que realmente dependem de toda a
> ACID.

Isso é absolutamente falso.


> O difícil está sendo convencer alguns gerentes a saírem do mundo relacional,
> e migrarem para novas tecnologias. O medo de trocar fazer uma troca dessa
> magnitude é grande, porém as vantagens são imensas, principalmente
> velocidade e diminuição de custos quando na nuvem.

Para de exibir sua ingenuidade!  Mil perdões, mas é isso.  Aprenda
relacional primeiro.


> Minha startup mesmo, migrou do Postgresql para o MongoDB, devido algumas
> necessidades específicas do modelo de negócio. Tive muitas melhorias até o
> momento.
> Sei que é difícil dizer isso, pois o Postgresql é como um irmão, cresceu
> comigo. Mas é preciso mudar as vezes.
>
> De qualquer forma, acho muito valido analisar o modelo de negócio, entender
> os tipos de noSQL e aplicar um MVP (produto minimamente viavel). Resultado
> agradou, migra. Ponto final.

E depois sofre as conseqüências da inexperiência e da falta de
conhecimento.  Ponto e vírgula.


-- 
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

Re: [pgbr-geral] [off-topic] Only NoSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-05 22:59 GMT-02:00 Vinícius Aquino do Vale <aquino.v...@gmail.com>:
>
> Em 5 de novembro de 2015 22:38, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>>
>> Claro que não.  Memcached é apenas um mecanismo para acelerar o acesso
>> físico a dados, independentemente do modelo, como o nome já indica:
>> MEMory CACHE Daemon, ou serviço de cache de memória.
>
> Só como complemento - https://pt.wikipedia.org/wiki/NoSQL

Infelizmente a Wikipedia em português é ainda pior que a inglesa nessa
área.  Praticamente inútil.

Aliás, o que isso tem a ver com o meu parágrafo que você citou?


> http://nosql-database.org/

Mera propaganda.  Você já leu o Codd?  Ou o Date?  Isso seria conhecimento.


-- 
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

Re: [pgbr-geral] [off-topic] Only NoSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-05 22:53 GMT-02:00 Vinícius Aquino do Vale :
>
> Bom, vejo várias startup e outras empresas mundo a fora adotando imensamente
> bancos noSQL

E muitos voltando ao SQL.  Como o Google.


> como eu disse o misto entre os dois é possível e muito usado
> atualmente.

E cada dia o PostgreSQL incorpora as técnicas de acesso, e diminui o
nicho do NoSQL.


> Todos os bancos que citei acima, são sim considerados noSQL. E nem todos são
> banco de dados, pois não fazem persistência, mas são noSQL. Bom, se está
> errado, vc terá que mudar o que está sendo falado e divulgado por ai, não
> fui eu que inventei.

Não tenho como mudar a ignorância geral.  Haja visto quão poucas
pessoas são capazes de sequer definir o que é o modelo relacional.
Tente.  Pode até pesquisar.


> E sim, aceite ou não, nem todos precisam de ACID, e o mundo noSQL encaixa
> perfeitamente para muitas delas. Existem startup's que fazem uso de noSQL, e
> o fazem muito bem, usando ou não relacional por trás.

Você havia dito que a maior parte das empresas não precisava de Acid.
Já mudou o tom.

E, infelizmente, /startup/ significa apenas ‘empresa iniciante’, com
um nome metido a besta.  Mais infelizmente ainda, a maior parte fecha
depois de pouco tempo, e ignorância sobre os fundamentos técnicos não
é a única razão, nem talvez a mais importante.


> Lembra do nome NoSQL- Not Only SQL - então "não somente SQL".

Isso foi a saída envergonhada que acharam quando o NoSQL de verdade se
mostrou um engodo.


-- 
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

Re: [pgbr-geral] Dúvida com TimeZone

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-16 14:29 GMT-03:00 Euler Taveira <eu...@timbira.com.br>:
> On 16-10-2015 12:59, Guimarães Faria Corcete DUTRA, Leandro wrote:
>>
>> O que creio que tinha de mudar é dar nomes às regiões.  Esse sistema
>> de cidades de referência não é óbvio o suficiente.
>>
> É uma boa ideia mas o Brasil não foi "recortado" pensando nisso.

Mas não precisa pensar nada.  Basta dar nomes ao recorte já feito.
Seria menos ambíguo que as cidades de referência.


> Para você
> ter uma ideia 13 municípios do Amazonas usam o mesmo fuso horário do Acre
> (UTC-5) [1].

Não sabia que era por municípios, achava que era somente uma linha
arbitrária.  Mas poderia ser chamado ‘Acre’ mesmo, ou ‘Amazônia
oriental’, ou qualquer coisa assim.


> Fusos horários são coisas de outro mundo. Se Santiago está mais ao oeste que
> Manaus porque ele possui o mesmo fuso de Brasília (que está ao leste de
> Manaus) [2]?

Afinidades e conveniências.  No caso, Santiago segue uma espécie de
‘horário do Cone Sul’, acompanhando Buenos Aires e Montevidéu, que por
sua vez acompanham o Brasil, meio que para ficar mais perto da Europa
que dos Andes.

Tem pior.  Os nazistas mudaram o fuso de Paris para ficar o mesmo de
Berlim e facilitar o planejamento do transporte ferroviário e
aeronáutico entre a Alemanha e a França ocupada, e os franceses nunca
mudaram de volta.  Assim, Paris está na mesma hora da Polônia até
hoje, embora tenha o mesmo horário solar de Londres.


-- 
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

Re: [pgbr-geral] Dúvida com TimeZone

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-16 12:10 GMT-03:00 Euler Taveira :
> O ideal é você utilizar o mais próximo possível da localidade da aplicação.

Sim, mas não exatamente.  Na verdade, esse sistema com nomes usa
cidades de referência.  Pode acontecer de você estar mais próximo de
uma cidade de referência fora do seu fuso.  O ideal era usar nomes de
regiões, como se não me falha a memória fazem na América do Norte, mas
no Brasil temos de relacionar as cidades e os fusos.  Assim, por
exemplo, Brasília fica perto de Tocantins, mas a cidade de referência
é São Paulo, mesmo, não Araguaína…


-- 
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

Re: [pgbr-geral] descobrir se telefone é celular

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-16 12:13 GMT-03:00 Carlos Antônio Pereira (VidaUTI)
:
> Tem alguma referência oficial para essa informação?
> http://www.teleco.com.br/num.asp
>
> Não deve ser oficial mas faz sentido.

Já ajuda, obrigado.  Aponta para http://www.teleco.com.br/num_cel.asp
que está desatualizado, então seria bom achar algo mais oficial e (ou)
atualizado.


-- 
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

Re: [pgbr-geral] descobrir se telefone é celular

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-16 11:46 GMT-03:00 Ivo Sestren Junior :
> Se começar com 6, 7, 8 ou 9 e tiver 8 ou 9 digitos é celular

Tem alguma referência oficial para essa informação?


-- 
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

Re: [pgbr-geral] Dúvida com TimeZone

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-16 12:24 GMT-03:00 Euler Taveira :
> Eu, por exemplo, uso America/Araguaina e não America/Sao_Paulo porque pode
> ser que no próximo ano o governo resolva voltar o horário de verão e eu não
> precisarei mexer na minha configuração.

Perfeito, porque ficas em Tocantins, não é?

O que creio que tinha de mudar é dar nomes às regiões.  Esse sistema
de cidades de referência não é óbvio o suficiente.


-- 
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

Re: [pgbr-geral] [OFF-TOPIC] Ajudem o Miguel

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-15 4:13 GMT-03:00 Shander Lyrio :
> ps: Um bom tempo fora da lista e quando retorno vejo que muita pouca coisa
> mudou...

Gente é gente, e os extorsionistas sabem criar uma mensagem que apele.
Veja que o colega foi motivado por suas emoções paternais, que em si
são louváveis.


-- 
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

Re: [pgbr-geral] [OFF-TOPIC] Ajudem o Miguel

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-14 18:40 GMT-03:00 Flavio Henrique Araque Gurgel :
>
> Tirem suas conclusões. Era só o que faltava, corrente (ainda por cima com
> 99% de chances de ser falsa) nesta lista séria.

O Debian tem um botão para denunciar /spam/ no arquivo da mensagem —
será que o PostgreSQL BR precisará disso também?


-- 
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

Re: [pgbr-geral] Questionamentos sobre performance.

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-08 10:13 GMT-03:00 Emerson Martins :
>
> Então a configuração física já encontra-se pronta lá no servidor do cliente,
> mas ainda teremos que rever esse RAID ai pois já havia comentado e avisado
> que não é o ideal.

Imagino que já o tenhas feito, mas avisa que é pior que ‘não o ideal’:
é absolutamente catastrófico.


-- 
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

Re: [pgbr-geral] Atualizando PostGreSQL, forma correta (procedimentos) ou melhor forma?

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-09 16:33 GMT-03:00 Rudimar :
>
> qual forma correta (procedimentos) ou melhor formar de se atualizar o
> PostGreSql? Sempre exporto tudo depois importo tudo, precisa configurar tudo
> novamente...

pgUpgrade, se não me falha a memória.


-- 
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

Re: [pgbr-geral] RES: Pgmail

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-07 9:59 GMT-03:00 Matheus Ferreira :
>
> Leandro o que você me mandou foi o link do google com a pesquisa pgmail
>
> http://www.google.com.br/search?q=pgmail_rd=cr=X&_q=1

Exato, Mateus — lá consta o pgMail e sua documentação.  O que queremos
saber, para poder ajudar, é: a partir daí, onde você chegou?  Ou olhou
para a lista de resultados e gelou?  Vai continuar no caminho do
pgMail, ou tentará o pgBarman como sugeriu o Gurgel?


-- 
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

Re: [pgbr-geral] Pgmail

[Guimarães Faria Corcete DUTRA , Leandro]

2015-10-06 14:43 GMT-03:00 Matheus Ferreira :
>
> Gostaria de saber se existe esse pgmail ...

http://www.google.com.br/search?q=pgmail_rd=cr=X&_q=1


> e se existe como configurar?

Vide documentos retornados na busca acima, venha com dúvidas específicas.



-- 
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

Re: [pgbr-geral] Importação de Base Sybase

[Guimarães Faria Corcete DUTRA , Leandro]

2015-09-06 21:15 GMT-03:00 Marcos Thomaz :
>
> @Leandro exatamente pelos motivos citados a cordialidade é muito bem vinda.
> Ironia e críticas beleza, mas não foi o caso.

Foi.


> Ao ler a mensagem, não fui
> somente eu quem ficou incomodado.

Toda vez que alguém na lista tem ataque de frescurite, é coletivo.
Pesquise o histórico.


> Lembro que por ser uma lista voluntaria, a
> cordialidade, educação e bom senso devem estar presentes sempre, evitando
> desgaste e lixo em mensagens para todos. Quanto a sua colocação do
> "nhem-nhem-nhem", o que fiz foi postar uma dúvida, simples e clara. Se isso
> é "nhem-nhem-nhem", não entendi o propósito de uma lista.

Vejo que você tem dificuldades de compreensão de texto.  O
nhem-nhem-nhem é a reclamação quanto à resposta do Flávio, não a
pergunta original.


> Como você mesmo
> disse.. não quer críticas não se pronuncie... e pela regra da boa educação,
> se não tem nada para contribuir, ficar quieto já ajuda bastante.

O Flávio contribuiu, e muito, para quem conseguiu (ou quis) entender.


> Novamente, faço a mesma colocação aqui para os moderadores e outros... se
> perguntas como a que eu fiz são inoportunas, desconsiderem, usem da
> moderação para evitar que vá ao ar. Não foi minha intenção gerar o atrito,
> mas o "dito pelo não dito" em comentários como o que foi feito, só denigrem
> a lista, prejudicam, e geram desconfortos como o que aconteceu agora.

CQD, ataque de não-me-toques.  Ou seja mais específico e diga
exatamente o que foi tão ofensivo na resposta do Flávio.



-- 
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

Re: [pgbr-geral] Cadastro de países e códigos postais

[Guimarães Faria Corcete DUTRA , Leandro]

2015-09-03 11:28 GMT-03:00 Ivo Sestren Junior :
>
> Mas existe países com vários nomes, principalmente se tratar com multi
> línguas.

Mas aí já são dois outros problemas.


-- 
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

Re: [pgbr-geral] Cadastro de países e códigos postais

[Guimarães Faria Corcete DUTRA , Leandro]

2015-09-02 19:57 GMT-03:00 Fabrízio de Royes Mello :
>
> O atributo "nome_pais" não seria a chave natural dessa relação? Creio
> que não existem dois países com mesmo nome no nosso planeta, ou existe?

Dependendo da carga de dados, pode haver conflito.  Do pacote
iso-codes do Debian:




Também conhecidos como Congo-Kinshasha (a ‘república democrática’, CD)
e Congo-Brazzavile (CG).

Mas claro, bastaria usar o nome completo e seria uma chave natural
perfeita.  Não a única; os códigos alpha_2, alpha_3 e numérico também
seriam chaves naturais.


> O mesmo vale para demais relações fazendo chave primária natural composta:
> - estado (nome_pais, nome_estado)
> - cidade (nome_pais, nome_estado, nome_cidade)
>
> IMHO é muito mais "natural" modelar assim ;-)

E ainda temos a alternativa de usar os códigos ISO, que eu prefiro.
No caso de ‘estado’ (província, cantão, departamento…) temos o ISO
3166-2, também no pacote ISO codes do Debian.  Acho mais prático usar
nomes mesmo para cidade, mas no caso do Brasil temos os códigos do
IBGE.


> Eu sei que os ORM usam o artificio de um ID sequencial, mas quem disse
> que eles estão fazendo a coisa certa falando em modelo relacional.

+1


-- 
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

Re: [pgbr-geral] HDD x SSDs

[Guimarães Faria Corcete DUTRA , Leandro]

2015-08-29 14:31 GMT-03:00 Wiliam Balan wiliamba...@gmail.com:

 Estou perguntando sobre as diferenças de configurações no SGBD, quando se
 está executando em SSDs, pois as diferenças (para melhor) são muitas, segue

Até aí, morreu o Neves.  Todo mundo sabe disso.  E daí?


 Outro ponto, é que o OTIMIZADOR do PostgreSQL (e de outros SGBDs também),
 são baseados em CUSTOS

Até aí, todo mundo sabe disso também.


 e os algoritmos internos do Otimizador, consideram
 custos de I/O baseado em tecnologia de discos magnéticos, ou seja, os custos
 são muito pessimistas se utilizarmos discos SSDs  e pensando que é o
 Otimizador que elabora os planos de execução das consultas e otimizações,
 vejo problemas ai.

Olha, faz tempo que não mexo com desempenho, infelizmente.  Mas se
você sabe disso, já olhou a referência dos parâmetros do PostgreSQL
para ver se há parâmetros de custos relativos de busca e de percorrer
estruturas?  Era assim que se fazia em Oracle, quando eu mexia com
isso, e nem lembro como era em PostgreSQL.  Mas, se você já chegou
onde chegou, também deve ter olhado a documentação, não?  Lembre-se
que isso não é específico de uso de memória de massa em memória não
volátil (/flash/): diferentes tecnologias de armazenamento magnético e
de memória viva já colocam as mesmas questões, e sempre foi assim.


 No artigo do link abaixo, segue uma proposta de um novo
 modelo de custos, que foi testado no PostgreSQL, nele os autores enfatizam
 isso que estou falando.

 https://www.dvs.tu-darmstadt.de/publications/pdf/BauschDaMoN2012.pdf

Resumindo para quem não vai parar para ler, foi implementado ou não?  Como?


 Se alguém ai, tiver outras dicas, sobre configuração do PostgreSQL
 específicas para discos SSDs, agradeço se puder me enviar, ou mesmo algum
 material específico para PostgreSQL em discos SSDs.

Isso dificilmente vai existir, visto armazenamento de massa em memória
/flash/ não colocar novidade nenhuma nesse campo.  Ou o sistema se
adapta automaticamente, se já chegamos lá, ou você tem de consultar a
referência dos parâmetros, que não lembro mais nem se chegaram a
existir.


-- 
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

Re: [pgbr-geral] RES: RES: RES: Espelhamento !!

[Guimarães Faria Corcete DUTRA , Leandro]

2015-08-25 11:18 GMT-03:00 Agape World Informática Ltda
ag...@agapeworld.com.br:

 Sim, posso mudar a base das lojas para 9.4 sem problema.

Por favor, sempre atualize para uma versão suportada,
preferencialmente a última, se possível antes de pedir ajuda.  Isso
facilita muito quem se propöe a te ajudar voluntariamente.

E, aproveitando, siga a netiqueta, começando por ler a RFC 1855.  Isso
seria sinal de αγαπε para com os outros participantes.  Já te pediram
para evitar as respostas no topo: evite também as frases mal formadas,
difíceis de entender; as mensagens formatadas (use texto simples); e
os sinais de exclamação desnecessários.  Se estiver difícil de
configurar o Micro$oft Outlook para respeitar as convenções da lista,
use um cliente livre como o Gnome Evolution, o Mozilla Thunderbird ou
o K-9.


-- 
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

Re: [pgbr-geral] Quais discos usar ?

[Guimarães Faria Corcete DUTRA , Leandro]

2015-07-31 11:43 GMT-03:00 Flávio Silveira f...@terra.com.br:

 On 31/07/2015 11:26, Raphael Coutinho wrote:
 A kingston tem uma vertente de SSD para Servidores chamada SSDNow!

 Desculpe postar aqui embaixo mas não gosto de top post.

Não precisa pedir desculpas por fazer o que é certo e seguir tanto as
boas práticas, quanto a regra da lista.  Aproveite e lembre também de
nunca escrever mensagens em HTML, e sempre cortar os trechos
irrelevantes à resposta na mensagem respondida e citada, como fiz.


   Em termos de SSD, os únicos dois fabricantes no qual eu confiaria meus 
 dados são Intel e Samsung, os outros sou bastante reticente.

Tens dados a respeito?


-- 
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

Re: [pgbr-geral] Quais discos usar ?

[Guimarães Faria Corcete DUTRA , Leandro]

2015-07-31 16:21 GMT-03:00 Vinícius Aquino do Vale aquino.v...@gmail.com:

 Se possível, penso que o ideal é que trabalhe com RAID 10

Raid 10 só faz sentido a partir da necessidade de espaço que supere o
que cabe numa unidade de armazenamento.  Com apenas 200 GB, cabe tudo
num espelho de 256 GiB.


-- 
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

Re: [pgbr-geral] Quais discos usar ?

[Guimarães Faria Corcete DUTRA , Leandro]

2015-07-31 17:31 GMT-03:00 Sebastian Webber sebast...@swebber.me:

 Em 31 de julho de 2015 17:23, Guimarães Faria Corcete DUTRA, Leandro
 l...@dutras.org escreveu:

 E aí Dutra, tudo bem?

Fora uma dorzinha de cabeça… e tu?


 Quanto ao tamanho, claro, o
 menor tamanho de disco pode atender a demanda do sistema, mas o ponto aqui
 não seria sugerir o melhor cenário?

Esse é o ponto chave, acho: não temos informação suficiente para
decidir qual o melhor cenário.  Eu, por exemplo, vi o consulente falar
em SSD, e presumi que ele já decidira ter orçamento para isso.  Mas
olhando o resto das informações prestadas, pode não ser o caso.

Realmente, se ele for crescer dos 200 GB, pode ser que SSD saiba muito
caro, e aí o SAS 15K RPM pode ser boa pedida.



-- 
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