from:"Alexsander Rosa"

Se os logs são descartáveis, porque não fazer o inverso? De tempos em
tempos, por exemplo todos os meses, pode-se fazer um dump só com os logs
(com a opção -t) e depois dar um TRUNCATE neles? Assim você pode arquivar os
logs para uso futuro e mantém o tamanho overall do banco dentro de um
limite mais aceitável.

Em 27/02/08, Christian Almeida [EMAIL PROTECTED] escreveu:

 Olá Lista!

 Há muito tempo estou inscrito nesta lista, porém quase nunca enviei
 perguntas, recorrendo à pesquisas no histórico dos posts e à documentação
 própria do Postgres. Mas infelizmente, neste caso, apesar de encontrar
 algumas informações a respeito, não consegui exatamente o que queria.

 Bem, vamos ao problema...

 Temos um banco com vários schemas e dentro dos schemas temos centenas de
 objetos (tabelas/views/sequences/etc...).

 Há algum tempo o arquivo de *dump* vem crescendo (e tende a ficar maior
 ainda) devido obviamente ao volume de registros. A idéia então é diminuir o
 tamanho do *dump* simplesmente removendo coisas descartáveis de dentro
 dele. Sendo asssim, analisamos a situação e chegamos a conclusão que em caso
 de emergência (onde será necessário restaurar todo o banco), os dados de
 algumas tabelas podem simplesmente ser descartados sem que prejudique a
 utilização do sistema (dados de *logs* por exemplo). O
 backup deverá restaurar todos os objetos (inclusive as tabelas cujo conteúdo
 pode ser descartado), bem como o restante dos dados.

 *Em resumo, eu preciso de gerar um dump que:*
 *- contenha a definição de todos os objetos dos schemas;  *
 *- contenha os dados de todas as tabelas, exceto de algumas tabelas as
 quais serão informadas no momento de geração do dump.*

 Eu gostaria que o dump fosse feito em um único arquivo. Contudo, caso não
 seja possível, ele pode ser feito em várias partes, cada uma contendo
 algum tipo de informação.

 Abraço.

 Christian.

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




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] LOG DAS QUERYS

Em teoria, daria para fazer uma replicação com isso, não?

2008/2/27, Osvaldo Rosario Kussama [EMAIL PROTECTED]:

 jota.comm escreveu:

 
  Depende de como o seu postgresql.conf sessão de log está configurado.
 

  2008/2/27, junior Prado [EMAIL PROTECTED]

  mailto:[EMAIL PROTECTED]:

 
  Gostaria de saber as querys executadas num determinado dia. Existe
  algum log padrão do postgres, ou possibilidade de habilitar o log?
 



 Depois de configurar a geração dos logs talvez você considere
 interessante utilizar o pgFouine para analisar os resultados.

 http://pgfouine.projects.postgresql.org/


 Osvaldo

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




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] LOG DAS QUERYS

Se replicar também os NEXTVAL, SETVAL, etc deve funcionar, não? Pergunto
porque estou fazendo uma replicação multimaster assíncrona na mão, via um
framework próprio. O problema é que a minha solução requer a criação de
algumas tabelas extras E que todos os comandos sejam feitos por dentro do
framewoek.

Na PGCon-Br me instigaram a tentar fazer uma versão genérica e lançar como
projeto open source.

2008/2/27, Thiago Risso [EMAIL PROTECTED]:

  Em teoria, daria para fazer uma replicação com isso, não?


 Em teoria SIM...
 Mas daria ALGUNS probleminhas .. principalmente com os DEFAULTS e
 Current_date, Current_time  Pois , a o replicar o COMANDO, ele
 iria inserir/Alterar de acordo com a VARIAVEL do SERVIDOR !!

 Mas .. pode ser tratado (Utilizando a data e hora do LOG talvez)... !!!

 --
 Att:

 Thiago Risso

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




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] LOG DAS QUERYS

Se puder mandar, eu agradeço.

Em 27/02/08, Thiago Risso [EMAIL PROTECTED] escreveu:

  Se replicar também os NEXTVAL, SETVAL, etc deve funcionar, não? Pergunto
  porque estou fazendo uma replicação multimaster assíncrona na mão, via
 um
  framework próprio. O problema é que a minha solução requer a criação de
  algumas tabelas extras E que todos os comandos sejam feitos por dentro
 do
  framewoek.
 
  Na PGCon-Br me instigaram a tentar fazer uma versão genérica e lançar
 como
  projeto open source.


 Tenho uma aplicação que desenvolvi justamente para isso  (Replicação
 Multimaster Assincrona) ... Funciona bem .. mas precisa de algumas
 melhorias... O Código está um pouco BAGUNÇADO... mas se alguém se
 interessar .. posso enviar o fonte (em C).

 Na época em que comentei isso na lista, gerou algumas discussões...
 mas ... está lá .. funciona bem ... assumindo os RISCOS de uma
 REPLICAÇÃO MULTIMASTER ASSINCRONA possui !

 ** É TRIGGER BASED ... então tem um arquivo de com SQLS que é
 preciso executar para criação das funções / SCHEMA / Tipos / Tables /
 Views /etc ...

 Bem ... se alguém se interessar por manter ou utilizar ... é só
 solicitar que eu envio !!
 Estava com um projeto de aprimorá-lo e desenvolver um webAdmin ...
 mas... estou meio sem tempo no momento ...


 Bem ... acho que é isso 


 --

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




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pesquisar mes dentro da data

2008-03-17 Por tôpico Alexsander Rosa

Pode usar o date_part [1]. Sintaxe:

SELECT nome FROM pessoa WHERE date_part('month',data_nascimento) = 4;

[1] http://www.postgresql.org/docs/current/static/functions-datetime.html

Em 17/03/08, Thiago Risso [EMAIL PROTECTED] escreveu:

   Use a função:
   EXTRACT(MONTH FROM TIMESTAMP sua_data)
   ou
   to_char(sua_datA, 'MM')


 Só pra complementar ... Normalmente uso o EXTRACT ou DATE_PART, pois
 com o TO_CHAR não da pra criar INDICES PARCIAIS, devido ao TO_CHAR
 depender de parâmetros externos como LOCALE para extrair o mês e
 portanto não é IMMUTABLE.!

 EX:
 trisso=# create index idx_foo_month on foo (to_char(data, 'MM'));
 ERROR:  functions in index expression must be marked IMMUTABLE

 trisso=# create index idx_foo_month on foo (EXTRACT(MONTH FROM data));
 CREATE INDEX
 trisso=#

 --
 Att:

 Thiago Risso

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




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
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 - Projeto que regulamenta p rofissões de informática foi aprovado na CCT - Senado Federal

2008-03-20 Por tôpico Alexsander Rosa

Discordo.

1º) Um médico pode praticar cirurgias com cadáveres, um farmacêutico pode
testar seus remédios em animais, um engenheiro pode construir em locais de
teste e fazer medições de cargas com equipamento adequado. Testes e ensaios
não são privilégios da Informática.

2º) Um bug num software também pode causar mortes. Em 1987 o equipamento de
radioterapia Therac-25 matou 5 pacientes; em novembro de 2000 o software de
planejamento de radioterapia da Multidata Systems matou 8 e deixou 20 com
graves seqüelas. Em 1991 uma falha de software do míssil Patriot (que
dispara automaticamente), da Raytheon, causou a morte de 28 soldados
americanos. O mesmo Patriot em 2003 abateu um caça Tornado GR-4 inglês por
engano, matando dois pilotos da RAF.

Naturalmente há inúmeros casos de prejuízos milionários. O foguete Ariane 5,
que explodiu em 1996 graças a uma falha de software, custou cerca de US$ 500
milhões (incluindo o satélite que seria lançado). Em 1990 a ATT teve uma
pane de 9 horas por causa de uma única linha de código: 75 milhões de
ligações e 200 mil reservas aéreas foram perdidas.

Em 17/03/08, Nabucodonosor Coutinho [EMAIL PROTECTED] escreveu:

 (...)
 A diferença entre informática e a comparação boba que vocês fazem com
 medicina e farmácia, é que em informática podemos testar e errar 100
 ou 1000 vezes para acertar uma. E se após acertar essa uma vez a gente
 não entendeu porque tudo funcionou, a gente pode testar de novo até
 entender e depois podemos testar de novo até aperfeiçoar.

 E podemos fazer tudo isso sem quaisquer tipo de prejuízos materiais
 que um médico, um farmaceutico ou um engenheiro civil poderia ter se
 tentasse fazer o mesmo.
 (...)



-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Bloqueio de usuário.

2008-03-26 Por tôpico Alexsander Rosa

Uma dica: em geral* isso não deveria causar problemas na aplicação... se
você usar os nomes das colunas nos comandos INSERT a aplicação pode ficar
rodando normalmente mesmo após a criação de novas colunas nas tabelas.

* Supondo que seja apenas uma coluna com informações extras não essenciais
às regras de negócio, claro.

2008/3/22, Brasil Software [EMAIL PROTECTED]:

 Bom dia amigos.

 Estou com um problema, presico bloquear a conexão do client enquanto
 estiver fazendo manutenção no banco de dados.
   EX:
 ALTER Table nometabel ADD codigo INTEGER;
ETC.
 Se alguem tiver uma solução para isto por favor me ajude.

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




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] CHAVE COMPOSTA

2008-04-09 Por tôpico Alexsander Rosa

Tenho aqui um ambiente misto com algumas chaves primárias artificiais e
outras naturais. Algumas das artificiais incluem código interno do
produto, código do cliente e número do pedido, todas obtidas através de
sequences.

Como o sistema é parcialmente replicado (ou parcialmente distribuído,
depende do ponto de vista), muitas das chaves primárias são compostas,
acrescentando o campo código da empresa para indicar a filial. Por
exemplo: se um cliente é cadastrado na filial 3 ele pode ficar com o código
1275/3 enquanto um outro, cadastrado na matriz (que é mais antiga e portanto
está com a sequence mais adiantada) fica com o código 45632/1. Da mesma
forma, os pedidos da filial 7 são números baixos como 2349/7 enquanto na
matriz já estão com 6 dígitos, por exemplo 170234/1.

O código do cliente precisou ser uma chave artificial porque há casos de
mais de um cliente com o mesmo CNPJ, em especial órgãos públicos. Por
exemplo, todas as escolas costumam usar o mesmo CNPJ da Secretaria de
Educação. Há casos em que o mesmo CNPJ aparece em 20 clientes diferentes.

Isso traz um problema: apesar de haver uma replicação multi-master
assíncrona entre as filiais e a matriz (desenvolvida internamente, usando
topologia em estrela), as sequences ficam com valores diferentes. Não dá pra
pegar o backup de uma empresa e colocar na outra sem rodar uma rotina para
dar um setval nas sequences colocando o max(chave) em todas elas.

Aproveito para perguntar: alguém tem uma sugestão para melhorar esta
modelagem? Uma das premissas básicas é que uma loja não pode deixar de
vender apenas porque a ADSL caiu (coisa que acontece toda semana). Nossa
sincronização suporta estas falhas de forma transparente, apenas atrasando a
replicação. A solução de conflitos é relativamente simples: em geral o
UPDATE mais antigo vence e há detecção de edição simultânea de uma tupla no
mesmo servidor através de timestamp.

Em 27/03/08, Leandro DUTRA [EMAIL PROTECTED] escreveu:

 2008/3/27, Evandro Ricardo Silvestre [EMAIL PROTECTED]:

  Concordo com relação a chave composta perfeitamente boa, mas não
   concordo que criar uma chave primária quando se pode ter uma chave
   composta vai aumentar tanto assim eventos de E/S e gasto de
   armazenamento.


 Não tem como dizer de antemão, tem de ser caso a caso.  E foi isso que
 questionei, dizer que sempre se cria uma chave artifical simples.
 Pode ser neutro, valer a pena ou penalizar; em caso de ser neutro ou
 penalizar, melhor ficar só com as naturais.




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Anúncio de emprego PostgreSQL

2008-04-19 Por tôpico Alexsander Rosa

Com CLT vai custar quase R$ 4 mil pro empregador.
Por isso muitos profissionais de TI usam CNPJ.

2008/4/20, Leandro DUTRA [EMAIL PROTECTED]:


 http://www.infojobs.com.br/OfertaVisualizar.aspx?id=1591704OrigenVisita=24mailpos=3alertaid=1212189envioid=85762566utm_source=infutm_medium=mailutm_campaign=cas

 R$2K é piada, mas de repente interessa para alguém.

 --
 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL 
 PROTECTED]
 +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Anúncio de emprego PostgreSQL

2008-04-20 Por tôpico Alexsander Rosa

Comentários abaixo.

2008/4/20, Leandro DUTRA [EMAIL PROTECTED]:

 2008/4/20, Alexsander Rosa [EMAIL PROTECTED]:

  Com CLT vai custar quase R$ 4 mil pro empregador.


 R$4K ainda é pouco, muito pouco para o responsável pelos dados de uma
 empresa decente.


De fato é pouco, mas não estou entrando neste mérito. Se fossem R$ 5 mil em
CLT iriam custar R$ 10 mil para o empregador... será que não seria melhor
pagar pelo menos parte desse dinheiro ao funcionário? Temos no Brasil uma
das legislações trabalhistas mais atrasadas do mundo, e isso gera desemprego
-- não na área de TI, onde as empresas têm até dificuldade para preencher as
vagas, mas em outras áreas que requerem menor qualificação.

 Por isso muitos profissionais de TI usam CNPJ.

 Nem vou comentar a sandice dessa abordagem para a área de dados.


Qual o problema? Existe alguma diferença de confiabilidade, por exemplo? Eu
acho mais comum o empregado via CLT descontente ficar na empresa pra não
perder a multa do FGTS do que o contratado via CNPJ, que quando está
descontente procura outro lugar para trabalhar com mais rapidez. Com CLT o
patrão pode ser mais cruel porque tem o empregado como refém, os
funcionários acabam agüentando ambientes desagradáveis por muito mais tempo.
E um empregado com vínculo empregatício, mas descontente, é muito menos
confiável do que um sem vínculo, mas satisfeito. Além disso, um NDA não
depende da forma de contratação.

--

 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL 
 PROTECTED]
 +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Anúncio de emprego PostgreSQL

2008-04-20 Por tôpico Alexsander Rosa

Eu respeito muito mais um profissional que prefere trabalhar por CNPJ do que
um que só trabalha se for por CLT. Pelo que vi em quase 20 anos de mercado,
quem faz questão de CLT (salvo honrosas exceções) em geral ou tem segundas
intenções (perfis de exemplo: batedor de ponto, moita, etc) ou não
confia muito no seu próprio taco. Tem gente que já entra no emprego pensando
na futura ação trabalhista que vai entrar, antes mesmo de começar a
trabalhar.

Em 21/04/08, Leandro DUTRA [EMAIL PROTECTED] escreveu:

 2008/4/21, Alexsander Rosa [EMAIL PROTECTED]:

  Você se ilude se pensa que a CLT é um indicativo de respeito, tanto por
  parte do empregador quanto por parte do empregado. Há inúmeros exemplos
 de
  maus patrões sugando os empregados porque sabem que eles não vão pedir
  demissão para não perder a multa do FGTS, assim como há maus empregados
  fazendo corpo mole de propósito apenas para ser demitidos.


 Distorções, mas o fato permanece.


 --

 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL 
 PROTECTED]
 +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,

Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Convertendo MDB (Access) para PostgreSQL

2008-05-07 Por tôpico Alexsander Rosa

1) Instale o mdb-tools
*sudo aptitude install mdb-tools*

2) Rode o seguinte comando:
*mdb-schema arquivo.MDB | sed -e s/Long// | sed -e s/Text/Varchar/ | sed
-e s/DateTime/Timestamp/ | sed -e s/Short/0/  esquema.sql
*Pode ser necessário acrescentar outros SED neste comando se o MDB tiver
algum outro tipo de dado não suportado.

3) Execute o script em anexo no arquivo MDB redirecionando para um arquivo.
*./dump-mdb.sh arquivo.MDB  dados.sql*

4) Pronto! O arquivo esquema.sql conterá o esquema e o arquivo dados.sql
conterá os dados.

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925


dump-mdb.sh
Description: Bourne shell script
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Convertendo MDB (Access) para PostgreSQL

2008-05-07 Por tôpico Alexsander Rosa

Eu pensei nisso, mas o mdb-tools tende a pegar os nomes dos campos em
maiúsculas.
O campo Textura ficará como TEXTURA (sem aspas) no script do esquema.

2008/5/7 Dickson Guedes [EMAIL PROTECTED]:

 Boa Alexsander!

 Alexsander Rosa escreveu:
 (...)
  2) Rode o seguinte comando:
  *mdb-schema arquivo.MDB | sed -e s/Long// | sed -e s/Text/Varchar/ |
  sed -e s/DateTime/Timestamp/ | sed -e s/Short/0/  esquema.sql
  *Pode ser necessário acrescentar outros SED neste comando se o MDB tiver
  algum outro tipo de dado não suportado.

 Apenas acrescentando para quem realmente for utilizar essa alternativa
 que fique atento para que palavras como /Textura/ por exemplo não
 sejam substituídas pelo /sed/ (experiência pŕopria)...

 Meus R$ 0,02
 --
 []s
 Dickson S. Guedes
 -
 Projeto Colmeia - Curitiba - PR
 (41) 3254-7130 ramal: 27
 http://makeall.wordpress.com/
 http://planeta.postgresql.org.br/
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] 2 cadastros em uma tabela

2008-05-14 Por tôpico Alexsander Rosa

Essa é uma questão sempre polêmica ...
Comentários abaixo

2008/5/7 Leandro DUTRA [EMAIL PROTECTED]:

 2008/5/7 Evandro Ricardo Silvestre [EMAIL PROTECTED]:
 
Isso vai gerar todo tipo de anomalia e complexidade...
   
Por exemplo, e se a pessoa for tanto cliente como fornecedor?
   
   Ou ela é cliente ou é fornecedor. O que pode acontecer de um fornecedor
   querer comprar algo da empresa, assim no momento de uma venda o
   fornecedor assume o papel do cliente. Mas ele não deixa de ser
   fornecedor (o que é a realidade).

 Não é 'a realidade', isso é como sua empresa modela a realidade.

 Você vai estar cheio de NULLs numa tabela muito mais gorda do que três
 tabelas separadas.  Você sempre vai ter de ler um atributo para saber
 como interpretar o resto.  A base não vai garantir as regras de
 negócio, engordando o aplicativo e garantindo a presença de
 inconsistências a médio prazo.


O que é uma tabela cheia de NULLs? Ter 3 ou 4 colunas com 90% dos valores
NULL numa tabela com 30 colunas é estar cheio de NULLs? O que é melhor,
desperdiçar alguns bytes ou ter que fazer um monte de JOINs pra fazer
qualquer consulta simples? Nessa mesma linha, cabe outra pergunta: o que é
uma tabela muito mais gorda?

Um outro exemplo: o endereço. Se uma pessoa (de qualquer tipo) pode ter
mais de um endereço, seria o caso de criar uma tabela endereço separada
com um relacionamento 1:N de modo de uma pessoa possa ter mais de um
endereço. O problema é que em 99,5% dos casos (acabei de conferir aqui pois
tenho um sistema modelado assim) o cliente tem apenas um endereço
cadastrado. Será que todo o trabalho necessário para buscar o endereço
compensa? Não seria mais fácil ter campos de endereço na própria tabela
pessoa e usar a tabela endereço apenas para os endereços alternativos? É
uma pergunta que já me fizeram várias vezes.


 Se for um sistema muito pequeno, dá para administrar.  Mas sempre será
 muito mais dor de cabeça que o necessário, e mais lento também.


O que é um sistema muito pequeno? Com até 100.000 registros na tabela
pessoa?



 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] 2 cadastros em uma tabela

2008-05-15 Por tôpico Alexsander Rosa

Obrigado pelos comentários de vocês.

Eu costumo normalizar tudo, e muitas vezes os programadores e outras pessoas
que precisam acessar as bases reclamam que precisam dar mil voltas pra
pegar as informações. Eu mesmo já me peguei reclamando dos meus próprios
modelos... hehehe. Por exemplo, costumo ter uma tabela pessoa e outras
tabelas para fornecedores, funcionários, etc. No caso dos endereços, que
citei no email anterior, sempre há quem reclame que pra pegar o endereço de
uma pessoa (em 99,5% dos casos existe apenas um por pessoa) é preciso ir lá
na tabela endereço.

Ando tão cansado que nem tenho mais saco pra ficar explicando os motivos. É
bom ver alguns comentários reforçando as minhas idéias de vez em quando. :-)

2008/5/15 Leandro DUTRA [EMAIL PROTECTED]:

 2008/5/15 Evandro Ricardo Silvestre [EMAIL PROTECTED]:
  Se eu condicionar a consultar para apenas *clientes* e tiver um indice
  no campo que indica a categoria da entidade (o campo utilizado para
  condicionar) vai continuar enchendo a memória com os fornecedores?

 Mais um índice, mais escritas, mais leitura, mais uso de cache, mais
 complexidade.

 Acredite, normalização foi criada por gente *muito* mais inteligente
 do que eu.  Não é uma simples técnica, é uma teoria de dependência
 funcional muito, muito bem pensada.

 Há exceções?  Há, pelo menos com a tecnologia atual.  Mas não passa
 disso, exceções.  Evite otimização precoce, que é a raiz de toda sorte
 de males.

 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-07 Por tôpico Alexsander Rosa

Eu vejo um problema em usar CNPJ como chave primária de clientes: os órgãos
públicos. Em geral vários órgãos diferentes, com nomes e endereços
diferentes, usam o mesmo CNPJ. Por exemplo, aqui no RS todas as escolas
estaduais usam o mesmo CNPJ, da Secretaria de Educação: 92.941.681/0001-00.
Para efeito de negócio são clientes diferentes, pois cada escola tem um
perfil e um histórico de compras diferente, um endereço diferente, uma
relação de compradores diferente, etc. Não seria interessante, do ponto de
vista do negócio, unificar todos no mesmo cadastro por causa de uma
restrição da modelagem de dados.

2008/6/20 Leandro DUTRA [EMAIL PROTECTED]:

 2008/6/20 Ribamar Sousa [EMAIL PROTECTED]:
 
  Bem, hoje o banco está com 13 tabelas, todas relacionadas mas percebo que
  uma grande maioria também deve ser adicionada num sistema real e
 importante.

 Muito bom enviar o script — e muito bom usar preferencialmente chaves
 naturais!

 Estávamos mesmo precisando de bons contra-exemplos ao Hybernate...

 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Alexsander Rosa

Já pensei em usar uma chave composta CPF_CNPJ + NUMERO (inteiro) onde o
campo numero seria uma sequencia de 1 até N, de acordo com o número de
escolas/hospitais/etc com o mesmo CNPJ. Poderia haver uma coluna booleana
orgao_publico e um CHECK para garantir que apenas tuplas com
orgao_publico TRUE possam ter numero  1.

2008/7/7 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/7 Alexsander Rosa [EMAIL PROTECTED]:
  Eu vejo um problema em usar CNPJ como chave primária de clientes: os
 órgãos
  públicos. Em geral vários órgãos diferentes, com nomes e endereços
  diferentes, usam o mesmo CNPJ.

 Não sabia dessa, boa.

 Será que seria o caso então de especializar entidades em públicas ou
 privadas?  Talvez não, visto que, na internacionalização, o modelo já
 ia se complicar mais também.

 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-17 Por tôpico Alexsander Rosa

No fim das contas todo mundo usa um código de cliente sequencial...
primeiro, porque é mais fácil de manipular um código que em geral fica com 5
ou 6 dígitos do que um CPF/CNPJ com 14 ou 15 dígitos. Segundo, porque há
casos em que o mesmo CNPJ é usado por mais de um cliente. Será que vale a
pena criar um monte de tabelas pra isso?

2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:

 2008/7/11 Johnny Taylor Faria Chaves [EMAIL PROTECTED]:

  Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.
 
  Daí pessoa jurídica ou física, mais duas tabelas.

 Há muito estou acompanhando aos pedaços essa discussão (nem vi onde ela
 saiu
 do estoque propriamente dito e entrou nessa de clientes, fornecedores e
 etc..., mas está ótimo).

 Leandro, agora chegou em um ponto que venho matutando desde que vi o
 desvio
 citado acima. Concordo que a solução é como você mostrou acima (pessoas=
 físicas| jurídicas + clientes| fornecedores) e facilita inserir sem
 duplicar
 dados (e esforços) funcionários (físicas), transportadoras (fornecedores e
 jurídicas), terceirizados (físicas ou jurídicas).

 Agora vem a pergunta, qual é (são) a(s) pk(s) disso tudo? Sequencial, você
 já
 mostrou sem sombra de dúvida que não pode ser (em qualquer contexto).
 CNPJ|
 CPF, como já debateram aqui, também está fora para a *grande maioria* dos
 casos.

 E mais, como você mesmo tem levantado ultimamente: *o domínio* dessa(s)
 pk(s),
 uma vez que parece que o Postgresql, nessa parte seguiu bem o padrão SQL,
 ou
 seja, fraco, quero dizer criar um domínio mesmo com operadores e tal.


 Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as
 coisas, física, jurídica, pública e privada, acredito que se deva usar
 nossos CPF e CNPJ.


 --
 Ribamar FS - [EMAIL PROTECTED]
 http://ribafs.net

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-18 Por tôpico Alexsander Rosa

Claro.

E depois, quando seu cliente quiser vender milhões de reais para 100 escolas
estaduais diferentes, todas com o mesmo CNPJ (da Secretaria de Educação),
você explica que o sistema não permite. O mesmo ocorre com hospitais,
universidades, etc. Não é apenas um endereço de entrega diferente, mas o
destinatário da NF diferente. Se a NF não for emitida EXATAMENTE como o
pessoal da licitação pede, você pode ter problemas na hora de receber o
empenho.

Além disso você vai misturar o histórico de compras, perfil do cliente etc
de todas as escolas. Mas isso é apenas um detalhe, claro.

2008/7/17 [EMAIL PROTECTED]:

 Desculpa, mandei para o Assunto errado.

 Tá mas no caso da duplicação de dados, o CNPJ ou CPF pode ser criado um
 index
 unique. Segunda coisa: CNPJ usado por mais de um cliente: o endereço do
 CNPJ é
 um só. Não existe o mesmo CNPJ com 2 endereços diferentes (Isso é lei). É
 só pedir o cartão de CNPJ para o cliente. Crie uma tabela com endereço de
 entrega. Resolverá o teu problema.

 Alecindro


 Quoting Leandro DUTRA [EMAIL PROTECTED]:

  2008/7/17 Alexsander Rosa [EMAIL PROTECTED]:
  No fim das contas todo mundo usa um código de cliente sequencial...
 
  E 'todo mundo' tem problemas de duplicação de dados...
 
 
  primeiro, porque é mais fácil de manipular um código que em geral fica
 com 5
  ou 6 dígitos do que um CPF/CNPJ com 14 ou 15 dígitos.
 
  Creio que já ficou claro que há muitas circunstâncias — melhor seria
  dizer muitas entidades — para as quais CNP[FJ] não serve.  Mas isso
  não é importante; o importante é ter pelo menos uma chave natural em
  cada relação.
 
 
  Segundo, porque há
  casos em que o mesmo CNPJ é usado por mais de um cliente. Será que vale
 a
  pena criar um monte de tabelas pra isso?
 
  Se você quer organização e consistência de dados, precisa normalizar.
 
  --
  skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
  +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
  +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
  +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 



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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Dois to_ascii (UTF-8) com resultados diferentes

2009-09-09 Por tôpico Alexsander Rosa

Eis o dump do psql (o banco é um 8.3.7 num Ubuntu 9.04):

select to_ascii(nome_cidade,'LATIN1') from cep_cidade where nome_cidade
ilike 'IUI%';
  to_ascii

 IUIU
 IUITEPORA
(2 registros)

cep=# select to_ascii(nome,'LATIN1') from tab_municipios where nome ilike
'IUI%';
 to_ascii
--
 IuiA
(1 registro)


Porque em minúsculas não está funcionando?

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Como criar uma FK checando um campo qualquer na tabela referenciada?

2010-01-04 Por tôpico Alexsander Rosa

Tenho duas tabelas, produto e estoque. Em produto a PK é código; há
também um par de campos (cod_base, quantidade) onde cod_base é uma FK
auto-referenciada. Este par serve para as embalagens: o produto 1234 pode
ser uma embalagem com 12 unidades do produto 1231 por exemplo. As unidades
(UN, CX, PCT, etc) são tratadas de acordo.

Na tabela estoque há um campo código_fk que é FK de produto. Somente
produtos-base (isto é, com NULL em cod_base) podem ter registros em
estoque. No entanto, às vezes um produto deixa de ser base e passa a ser
embalagem*, deixando registros sobrando na tabela estoque; tenho que
controlar isso via aplicação mas gostaria de usar o SGBD para garantir esta
integridade de forma mais efetiva.

Segundo sugestão do IRC, tentei criar uma coluna extra em estoque, deixada
sempre em NULL, criando uma nova FK em estoque usando os dois campos de
produto (cod_produto e cod_base). Consegui criar esta constraint mas ela
não funcionou: valores inválidos ainda puderam ser inseridos.

* Exemplo: um blister com 4 pilhas é vendido como base e vem numa
embalagem com 50 blisters. Um dia o fabricante resolve fazer blisters com 2
pilhas -- ou o lojista resolve abrir os blisters e vender as pilhas
individualmente.

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Alexsander Rosa

Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave
natural, o que é impossível porque inúmeros órgãos públicos compartilham o
mesmo CNPJ. Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais
usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro.
Para o pagamento de empenhos os nomes das escolas precisam estar corretos
até a última vírgula, não dá pra emitir a NF em nome da Secretaria e depois
mandar entregar na escola. É muito mais simples usar um SERIAL para código
de cliente do que tentar achar uma chave natural viável.

Sou totalmente a favor de chaves naturais, uso sempre que possível, mas há
casos em que simplesmente não dá.

2010/1/4 Leandro DUTRA leandro.gfc.du...@gmail.com


 Não.  Nunca falei isso.  Falei que geralmente chave artificial é
 desnecessária; não que é sempre desnecessária.  E, aliás, que o que
 menos me importa é qual seja a chave primária, ou qual chave será
 ‘exportada’ (não nesta discussão, talvez).
 (...)
 O problema não é a existência do SERIAL, é seu uso — e abuso.

 Para bom entendedor… fica claro que o que exijo é chave natural,
 independente de ser primária ou alternativa, e que prefiro que não
 haja artificial a não ser que o desempenho exija.



-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como criar uma FK checando um campo qualquer na tabela referenciada?

2010-01-04 Por tôpico Alexsander Rosa

Segue exemplo. O último comando gera uma inconsistência que eu gostaria de
poder evitar via constraint. A inconsistência é a seguinte: somente
produtos-base deveriam ter estoque; neste caso o usuário deve primeiro
eliminar o endereço do estoque (movendo os pallets ou algo que o valha) para
depois mudar as associações produto-embalagem. Hoje preciso controlar isso
via aplicação mas gostaria de ter mais um nível de controle de consistência
no banco.

2010/1/4 JotaComm jota.c...@gmail.com

 Olá,

 2010/1/4 Alexsander Rosa alexsander.r...@gmail.com

 Tenho duas tabelas, produto e estoque. Em produto a PK é código; há
 também um par de campos (cod_base, quantidade) onde cod_base é uma FK
 auto-referenciada. Este par serve para as embalagens: o produto 1234 pode
 ser uma embalagem com 12 unidades do produto 1231 por exemplo. As unidades
 (UN, CX, PCT, etc) são tratadas de acordo.

 Na tabela estoque há um campo código_fk que é FK de produto. Somente
 produtos-base (isto é, com NULL em cod_base) podem ter registros em
 estoque. No entanto, às vezes um produto deixa de ser base e passa a ser
 embalagem*, deixando registros sobrando na tabela estoque; tenho que
 controlar isso via aplicação mas gostaria de usar o SGBD para garantir esta
 integridade de forma mais efetiva.

 Segundo sugestão do IRC, tentei criar uma coluna extra em estoque,
 deixada sempre em NULL, criando uma nova FK em estoque usando os dois
 campos de produto (cod_produto e cod_base). Consegui criar esta constraint
 mas ela não funcionou: valores inválidos ainda puderam ser inseridos.

 * Exemplo: um blister com 4 pilhas é vendido como base e vem numa
 embalagem com 50 blisters. Um dia o fabricante resolve fazer blisters com 2
 pilhas -- ou o lojista resolve abrir os blisters e vender as pilhas
 individualmente.


 Não entendi. Teria como colocar um exemplo mais claro, por exemplo com o
 valor que segundo você comentou que foi inserido e não poderia ter
 acontecido.




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
CREATE TABLE tmp_produto (
  cod_prod integer primary key,
  descricao text,
  prod_base integer,
  caixa_com integer,
  FOREIGN KEY (prod_base) REFERENCES tmp_produto(cod_prod)
  );

CREATE UNIQUE INDEX idx_tmp_prodbase ON tmp_produto(cod_prod,prod_base);

CREATE TABLE tmp_estoque (
  posicao_pallet varchar(10) primary key,
  cod_prod_fk integer not null,
  campo_nulo integer,
  quantidade integer,
  FOREIGN KEY (cod_prod_fk) REFERENCES tmp_produto(cod_prod),
  FOREIGN KEY (cod_prod_fk,campo_nulo) REFERENCES tmp_produto(cod_prod,prod_base)
  );

-- cria um produto e seu estoque
INSERT INTO tmp_produto VALUES(314,'BLISTER COM DUAS PILHAS',null,null);
INSERT INTO tmp_estoque VALUES('ABC-1234',314,null,10);

-- cria um novo produto-base
INSERT INTO tmp_produto VALUES(315,'BLISTER COM UMA PILHA',null,null);
UPDATE tmp_produto SET prod_base = 315, caixa_com = 2 WHERE cod_prod = 314;



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

Re: [pgbr-geral] Como criar uma FK checando um campo qualquer na tabela referenciada?

2010-01-06 Por tôpico Alexsander Rosa

Fabrizio, testei neste exemplo e parece ter funcionado.
Vou implementar no BD de desenvolvimento e aviso.
Abraços
Alex

2010/1/5 Fabrízio de Royes Mello fabriziome...@gmail.com



 2010/1/4 Alexsander Rosa alexsander.r...@gmail.com

 Segue exemplo. O último comando gera uma inconsistência que eu gostaria de
 poder evitar via constraint. A inconsistência é a seguinte: somente
 produtos-base deveriam ter estoque; neste caso o usuário deve primeiro
 eliminar o endereço do estoque (movendo os pallets ou algo que o valha) para
 depois mudar as associações produto-embalagem. Hoje preciso controlar isso
 via aplicação mas gostaria de ter mais um nível de controle de consistência
 no banco.


 Caro Alexsander,

 Quem sabe a alternativa em anexo seja uma opção... note as modificações que
 fiz (campo tipo na tabela produtos e tipo na tabela de estoques)...

 Verifique e voltamos a discutir...

 Cordialmente,


 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-07 Por tôpico Alexsander Rosa

Comentários no texto.

2010/1/7 Leandro DUTRA leandro.gfc.du...@gmail.com

 2010/1/4 Alexsander Rosa alexsander.r...@gmail.com:
  Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave
  natural, o que é impossível porque inúmeros órgãos públicos compartilham
 o
  mesmo CNPJ.

 Há vários motivos pelos quais CNPF ou CNPJ podem não ser chave natural
 — a questão que se coloca é, justamente, de qual entidade?

 A entidade cliente, por exemplo. Ou quem sabe, fornecedor. Talvez
exista uma entidade pessoa que contém apenas os dados básicos (nome,
cpf/cnpj, etc) e as demais, como cliente, fornecedor, funcionário, etc
sejam especializações. De qualquer forma, não é prático usar, digamos, o
nome completo (+ nome da mãe para o caso dos homônimos): imagine um setor da
empresa conversando com outro, por telefone, sobre um cliente específico.
Além do tempo perdido ditando nomes potencialmente extensos, podem haver
clientes homônimos ou mesmo com grafia ou sonoridade similar. Um código
numérico faz muito mais sentido.


 Acho que eu mesmo já citei o caso de correntista de banco.  Há, por
 exemplo, mulheres casadas que não têm CNPF, porque nunca tiveram vida
 economicamente ativa, mas têm conta conjunta com o marido.  São
 correntistas sem CNPF.

 No teu caso, já poderíamos pensar numa entidade órgão público, que
 certamente tem outra chave.  Talvez, várias entidades.  Se é prático
 ou não separá-los numa base de dados, vai depender de muitas
 variáveis, como dialeto SQL, implementação física, volume de dados,
 tráfego de transações, ferramental de programação… mas, se não
 analisarmos as entidades — e para isso chaves naturais são
 indispensáveis, mesmo que acabem não sendo implementadas nalgum caso
 extremo —, nunca entenderemos os problemas.

 Tradicionalmente as empresas criam um código de cliente para cada cliente
mas permitem que eles cheguem no balcão munidos apenas com o CPF e localizem
seu registro. A chave natural não deixa de existir, apenas não é primária.


  Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais
  usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro.
  Para o pagamento de empenhos os nomes das escolas precisam estar corretos
  até a última vírgula, não dá pra emitir a NF em nome da Secretaria e
 depois
  mandar entregar na escola.

 No mínimo, há uma entidade escola estadual cuja chave não é o CNPJ.
 Talvez o nome da escola, por exemplo (sei, sei, nome dificilmente é
 boa chave, só para provocar a pensar), ou até o nome e o endereço.

 Indo por este caminho acabaríamos criando entidades para escolas (cuja
chave primária pode ser o código INEP, como foi dito aqui), agências dos
correios (cada agência tem seu número), agências de alguns bancos públicos
(nº do banco + nº da agência), sedes do SESC (deve haver algum código que
eles usam) e assim por diante.


  É muito mais simples usar um SERIAL para código
  de cliente do que tentar achar uma chave natural viável.

 Sim, mas incorreto.

 Sendo mais preciso, pode ser necessária uma chave artificial; mas não
 tentar uma chave natural, mesmo que não seja declarada como a
 primária, seria convidar problemas pela porta da frente.

 Mas este é o processo: tentar em primeiro lugar uma chave natural como
chave primária. Mantenho o uso de chaves artificiais dentro do mínimo
necessário. Outro exemplo é o de código de produto: há quem use código de
barras como chave primária, mas nem todo produto tem código de barras.
Alguns são tão pequenos que é impossível sequer colocar uma etiqueta ou
similar, e outros ainda são adquiridos do mesmo fornecedor com códigos de
barras diferentes, por motivos que vão desde erro de impressão da embalagem
até origens diferentes.


  Sou totalmente a favor de chaves naturais, uso sempre que possível, mas
 há
  casos em que simplesmente não dá.

 Não dá o quê?

 Não dá para usar como chave primária, não estou preocupado.

 Não dá para declarar, estou para ver um caso.

 Eu me refiro a usar como chave primária.

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-07 Por tôpico Alexsander Rosa

Que bom que acabamos nos entendendo...

2010/1/7 Leandro DUTRA leandro.gfc.du...@gmail.com


  De qualquer forma, não é prático usar, digamos, o nome
  completo (+ nome da mãe para o caso dos homônimos): imagine um setor da
  empresa conversando com outro, por telefone, sobre um cliente específico.

 Usar como?

 Usar como chave primária, ou como única chave, provavelmente.

 Já declarar como chave natural, ainda que não a primária, é necessário
 para evitar duplicações.

 Especificamente nesse exemplo, provavelmente precise-se de uma chave
 composta, visto que mesmo o conjunto de nome e filiação não costuma
 ser chave.

 Sim, eu me referia a usar como chave primária.

Agora uma curiosidade: um ex-colega de faculdade se chamava TÉLVIO e tinha
um irmão gêmeo chamado TÉLCIO. O irmão fez o título de eleitor primeiro e
meu colega não conseguiu tirar o título -- pelo menos até a época da
formatura. O sistema do TRE achou que era fraude, pois eles tinham os nomes
muito parecidos, mudando apenas uma letra, e tinham data de nascimento e
nome da mãe iguais. Ele deve estar com quase 40 anos hoje; não sei se
conseguiu votar algum dia.


  Extremismo na defesa da liberdade não é defeito.
  Moderação na busca por justiça não é virtude.
  -- Barry Goldwater

 Hm, acho que não concordo… OT!  :-)

 Com o extremismo ou com a moderação? :-)

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho das tabelas!

2010-01-12 Por tôpico Alexsander Rosa

Troque a palavra 'seu_esquema' pelo nome do seu esquema.
Experimente colocar 'public', que é o nome padrão.

2010/1/12 Glênio Côrtes Himmen glenio.116...@aparecida.go.gov.br

  Irmão,

 Os comandos abaixo redam em 15ms, mas não me retornam nada.

 Diretoria de Tecnologia da Informação
 Prefeitura Municipal de Aparecida de Goiânia
 Rua Gervasio Pinheiro, Residêncial Solar Central Parque
 Aparecida de Goiânia-GO - CEP - 74.968-500
 Glênio Côrtes Himmen - glenio.116...@aparecida.go.gov.br
 http://www.aparecida.go.gov.br

 Não declines nem para a direita nem
 para a esquerda, retira o teu pé do mal.

 Pv. 4:27

 - Original Message -
 *From:* JotaComm jota.c...@gmail.com
 *To:* Comunidade PostgreSQL Brasileirapgbr-geral@listas.postgresql.org.br
 *Sent:* Tuesday, January 12, 2010 3:22 PM
 *Subject:* Re: [pgbr-geral] Tamanho das tabelas!

 Olá,

 2010/1/12 Glênio Côrtes Himmen glenio.116...@aparecida.go.gov.br

 Como que posso saber o tamanho de cada uma das tabelas do meu esquema?


 Sem contas os índices:

 SELECT table_name,pg_size_pretty(pg_relation_size(table_name)) AS tamanho
 FROM information_schema.tables
 WHERE table_schema='seu_esquema'
 ORDER BY 2 DESC;

 Contando os índices:

 SELECT table_name,pg_size_pretty(pg_total_relation_size(table_name)) AS
 tamanho
 FROM information_schema.tables
 WHERE table_schema='seu_esquema'
 ORDER BY 2 DESC;




 Diretoria de Tecnologia da Informação
 Prefeitura Municipal de Aparecida de Goiânia
 Rua Gervasio Pinheiro, Residêncial Solar Central Parque
 Aparecida de Goiânia-GO - CEP - 74.968-500
 Glênio Côrtes Himmen - glenio.116...@aparecida.go.gov.br
 http://www.aparecida.go.gov.br

 Não declines nem para a direita nem
 para a esquerda, retira o teu pé do mal.

 Pv. 4:27

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



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com

 --

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


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho das tabelas!

2010-01-12 Por tôpico Alexsander Rosa

Qual o resultado do SQL abaixo?

*select catalog_name, schema_name from information_schema.schemata order by
2;
*
PS: Estou testando pelo psql.

Alex

2010/1/12 Glênio Côrtes Himmen glenio.116...@aparecida.go.gov.br

  Sou novato em Postgresql mas nem tanto, quando rodei o comando, eu
 substitui a palavra seu esquema por sch que é o nome do meu esquema.

 Afirmando novamente, não retornou nada.





-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual o melhor Sistema Operacional?

2010-01-21 Por tôpico Alexsander Rosa

Linux rulez!
FLAME MODE ON

2010/1/21 Marcos André mac.poa...@gmail.com

 Olá Srs.,

   Estou para criar um servidor de banco de dados PostgreSQL e neste momento
 nos veio a seguinte dúvida Qual o melhor Sistema Operacional? e para isto
 estou fazendo um estudo e através da experiencia da comunidade eu preciso
 saber quais as melhores opções para este tópico.



-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Número de transações por dia

Falando nisso, como se calcula este número de transações por dia de modo
coloquial, sem uma formalidade tipo TpmC (com benchmark da TPC)? São
apenas as transações (com begin/commit), apenas os comandos SQL de
modificação (insert, update e delete) ou todos os comandos feitos no dia,
incluindo os select?

Existe algum tipo de ferramenta para determinar estes números (sem
considerar os benchmarks da TPC, claro)? Alguma configuração do
postgresql.conf ou alguma tabela do information_schema?

Aqui eu faço a replicação via log shipping de comandos I/U/D, portanto
consigo medir o volume de gravações no banco -- são cerca de 200 mil por dia
de semana (exceto sábado, pois as lojas funcionam apenas em horário
comercial) -- mas não tenho estatística dos select que são feitos. Já fiz
depuração statement-por-statement, incluindo os select, mas nunca levantei
esta estatística. Esta análise foi feita em especial no início do
desenvolvimento (para otimizar o framework); hoje em dia, faço apenas
eventualmente para achar algum bug mais cabeludo.

2010/1/21 Leandro DUTRA leandro.gfc.du...@gmail.com

 2010/1/21 Jurandir Dallabeneta li...@lmd.com.br:
  Possuimos um software de monitoramento de chão de fábrica onde 5 cpus
  fazem leituras a partir de CLP's e gravam num banco de dados central.
  A base tem 5gb atualmente com aproximadamente 50.000 transações dia.
 
  Pasmen... Windows 2008 Server 64bits.
  Funciona sem problemas a meses, tudo com bom backup.

 A base é pequena, as transações ridiculamente poucas.

 Me fala de terabytes e centenas de transações por segundo… mesmo isso
 dá para fazer funcionar em MS Windows, até em MS SQL Server.  A
 questão é o preço, a falta de liberdade, e a dor de cabeça — não nessa
 ordem.




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Número de transações por dia

Com este SELECT que você me passou, depois de resetar, deu mais de 33.000
transações em 5 minutos... entre 11:46 e 11:51. Imagino que este dado deva
considerar os SELECT também, mas mesmo assim ficou acima do que eu pensava.

2010/1/22 JotaComm jota.c...@gmail.com


 A partir do catálogo você consegue este tipo de informação:

 SELECT datname,numbackends,xact_commit,xact_rollback FROM pg_stat_database;

  Este select apresenta o nome do banco, número de conexões, número de
 commits e de rollbacks. Porém, isso é a somatória total, para medir
 dia-a-dia, hora-a-hora você poderia fazer um script para executar
 diariamente e capturar estas informações.

 E um bom passo para começar seria zerar estatísticas e isso você pode fazer
 por meio da função: pg_stat_reset().

 Ainda acredito que a medição via alguma ferramenta seria o melhor caminho.




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Número de transações por dia

Pois é, foram mais de 365.000 transações em 2:30 horas.

2010/1/22 JotaComm jota.c...@gmail.com

 Olá, Alexander

 2010/1/22 Alexsander Rosa alexsander.r...@gmail.com

 Com este SELECT que você me passou, depois de resetar, deu mais de 33.000
 transações em 5 minutos... entre 11:46 e 11:51. Imagino que este dado deva
 considerar os SELECT também, mas mesmo assim ficou acima do que eu pensava.


 Sim. Ele considera SELECT também.


 2010/1/22 JotaComm jota.c...@gmail.com


 A partir do catálogo você consegue este tipo de informação:

 SELECT datname,numbackends,xact_commit,xact_rollback FROM
 pg_stat_database;



-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] erro de newbie - perdi a senha - preciso mudar o banco de micro

Talvez isso aqui te ajude, com alguma adaptação:
http://cristianogd.blogspot.com/2010/01/recuperar-restaurar-base-de-dados.html

2010/1/22 mrdan pir149...@terra.com.br

Desculpem se o tópico for muito fácil, mas eu tô apanhando faz uns dois
dias
com isso, e a cada vez eu pioro a situação
Estou desenvolvendo uma aplicação e adotei o POSTGRESQL como banco. A duras
penas, criei um banco e diversas tabelas, usuários para acesso e estou na
fase final de testes. Minha aplicação acessa sem problemas, e tudo ia bem.
Nessa etapa, eu tenho que passar o banco para o servidor (ele está
instalado
no meu micro, durante o desenvolvimento). Fuçando a net, achei instruções
para fazer isso com o pg_dump e/ou o pg_dumpall. Bom, executei pg_dump
banco
saida.txt, e gerou um arquivo ... no servidor, instalei o Postgres e
tentei psql banco saida.txt ai a coisa começou a ficar
interessante.
Perguntas :
1) eu tenho que ter o banco criado no 2o. micro antes dessa importação ?
2) Se sim, devo criar na mão ?
3) Tem alguma ferramenta que simplesmente tire tudo de um micro e recrie em
outro ?
Nas tentativas, comecei a ter problemas com senha (nao me perguntem o que
fiz, eu acabei perdendo a senha do banco original). Agora minha aplicação
consegue ler/gravar, mas o pg_admin não mais ... e se eu tento importar no
novo, dá erros e mais erros ...
Enfim, a situação é :
a) tenho um arquivo gerado pela cópia de segurança do pg_admin
b) tenho dois arquivos de objetos globais e (acho) dos bancos criados
pelo pg_admin antes de dar pau na senha
c) preciso recriar os bancos no micro novo. Os dados não me interessam, são
só massa de testes, mas a estrutura sim ...
d) o problema de senha apareceu qdo eu mexi no arq. pg_hba.conf, conforme
eu
tinha acado uma dica na net ... passei o acesso de md5 para trust ja
voltei ao que era, mas nada
e) eu vou entrar em desespero ...

eu tenho a impressão que meu embróglio deve ser fácil de resolver, mas eu
realmente não sei por onde começar please alguma alma caridosa e mais
experiente que eu pode me ajudar ? tks

--
View this message in context:
http://old.nabble.com/erro-de-newbie---perdi-a-senha---preciso-mudar-o-banco-de-micro-tp27278666p27278666.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

--
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Acesso a base de dados física

Algo me diz que ele não está preocupado com bobagens feitas pelo root, mas
sim com pirataria. Uma aplicação comercial e closed-source pode ter schema
+ stored procedures copiados. Se for em PHP, então... tudo está disponível.

2010/1/20 Osvaldo Kussama osvaldo.kuss...@gmail.com

 2010/1/20 Vinicius Santos vinicius.santos.li...@gmail.com:
  Sim. Basta que esse usuário *não* seja super-usuário do SO e nem o
 usuário que
  executa o PostgreSQL (senão ele pode modificar o pg_hba.conf). Além
 disso,
  certifique-se que *não* esteja utilizando ident (caso haja um usuário no
 SO
  com mesmo nome de um usuário no PostgreSQL) e que as conexões do tipo
 'local'
  estejam utilizando um método de autenticação diferente de 'trust',
 'ident' e
  'password'.
 
  Esse é o problema, o usuário é super-usuário do SO e tem acesso ao
  pg_hba.conf.

 Mas vocês não confiam no cara que é o super-usuário da instalação?
 Neste caso não seria mais prático demití-lo?


 
  Acho que teremos que resolver isso com soluções comerciais. =(

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho em bytes de Tabela Vazia

2010-01-27 Por tôpico Alexsander Rosa

http://www.postgresql.org/docs/current/static/datatype-character.html

The storage requirement for a short string (up to 126 bytes) is 1 byte plus
the actual string, which includes the space padding in the case of character.
Longer strings have 4 bytes of overhead instead of 1. Long strings are
compressed by the system automatically, so the physical requirement on disk
might be less.

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Usando CPF/CNPJ como PK

Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me
incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave
primária natural porque, conforme já foi dito aqui várias vezes, muitos
clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para
dar um exemplo: temos um cliente que tem várias CENTENAS de clientes -- a
imensa maioria, escolas da rede estadual -- com o mesmo CNPJ
(92.941.681/0001-00), que segundo a Receita Federal está registrado em nome
da Secretaria da Educação do RS.

Uma possibilidade é usar uma chave composta, tipo CNPJ + chave extra onde
esta chave extra tem NULL em todas as PF e quase todas as PJ. Quando uma PJ
pertencer a mais de um cliente (órgãos públicos, universidades, etc), esta
chave extra conterá um código (numérico? texto?) que identificará cada
unidade. Para escolas, poderia ser um código tipo INEP, por exemplo. Em
universidades poderia ser algum código que identifique o setor.

Alguém tem alguma sugestão para isto?

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
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 Comparação Dados Tabel as

Sei de algumas que geral instruções DDL para sincronizar esquemas, seria
interessante usar para DML para sincronizar os dados -- se bem que na
maioria das vezes um DUMP/RESTORE resolve o problema. :-) Imagino que seja
algo que precise ser rodado de tempos em tempos, em produção, sem a
possibilidade de um downtime para esta atualização.

Em 3 de março de 2010 10:28, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:

 Pessoal,

 Alguém conhece alguma ferramenta *free* ou *gpl* para comparar os dados de
 tabelas de 2 bases de dados distintas... preciso fazer um diff dos dados
 entre tabelas que o resultado fosse instruções DML para atualização dos
 registros.

 Conheço algumas soluções proprietárias, mas antes de decidir por alguma
 aquisição gostaria de avaliar alguma alternativa gratuita e, se possível,
 open-source.

 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

Sim, na verdade eu editei o texto várias vezes e este detalhe passou
despercebido. Este campo, chave_extra, ficaria com um valor tipo 0 (se for
inteiro) ou brancos (se for texto) na maioria dos casos. Mas tenho minhas
dúvidas se esta é mesmo a melhor solução, acho que no fim vai ser melhor
usar uma chave artificial, a famosa código do cliente.

Existe também o problema da replicação. Cada filial tem um servidor
(replicado) e nenhuma loja pode parar por falta de Internet ou falta de
comunicação com a Matriz. Sei que muitas empresas simplesmente param quando
isso acontece, com a tradicional explicação de que estamos sem sistema,
mas nós nunca achamos isto aceitável -- especialmente no caso das redes de
varejo. Além disso, a legislação praticamente exige que o software de PDV
emita cupons mesmo com o cabo de rede cortado.

Neste cenário, cada servidor tem suas (poucas) SEQUENCES independentes
(estão fora da replicação) e as PK de algumas tabelas são chaves compostas
que incluem a coluna id_servidor. Os clientes acabam recebendo um código
que costuma ser exibido no formato 9502/1 (código 9502 do servidor 1) e os
JOINS precisam sempre considerar isto. Não chega a ser nada desesperador,
mas nesta reforma vamos reduzir o uso de chaves artificiais ao mínimo
necessário -- como, talvez, esta tabela de pessoas.

Por enquanto, sem ter ainda me aprofundado nesta reforma (são centenas de
tabelas), acho difícil escapar de pelo menos três chaves artificiais: código
da pessoa, código do produto e número do pedido.


Em 4 de março de 2010 15:24, Osvaldo Kussama
osvaldo.kuss...@gmail.comescreveu:

 Em 4 de março de 2010 13:28, Alexsander Rosa
 alexsander.r...@gmail.com escreveu:
 
  Uma possibilidade é usar uma chave composta, tipo CNPJ + chave extra
 onde
  esta chave extra tem NULL em todas as PF e quase todas as PJ. Quando uma
 PJ
  pertencer a mais de um cliente (órgãos públicos, universidades, etc),
 esta
  chave extra conterá um código (numérico? texto?) que identificará cada
  unidade. Para escolas, poderia ser um código tipo INEP, por exemplo. Em
  universidades poderia ser algum código que identifique o setor.
 
  Alguém tem alguma sugestão para isto?


 Apenas uma observação: uma chave primária não pode conter NULL em
 nenhum dos campos que a compõe.
 Não ficou claro se quando você diz chave composta está ou não se
 referindo a chave primária.

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

Leandro:

Em 4 de março de 2010 16:30, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com:

  Neste cenário, cada servidor tem suas (poucas) SEQUENCES independentes
  (estão fora da replicação) e as PK de algumas tabelas são chaves
 compostas
  que incluem a coluna id_servidor. Os clientes acabam recebendo um
 código
  que costuma ser exibido no formato 9502/1 (código 9502 do servidor 1)

 Essa informação depois é replicada para outros servidores?


Sim, tudo é replicado para todos os servidores (exceto as sequences).
Provavelmente existem pessoas 9502/2, 9502/16, 9502/101, etc criadas em
momentos bem diferentes, de acordo com as datas de inauguração de cada
filial. Números baixos costumam aparecer dezenas de vezes, um para cada
filial. Por outro lado, números mais altos geralmente só aparecem nas lojas
mais antigas.

Lembrando que muitas vezes nós somos o ENÉSIMO sistema implantado e acabamos
herdando cadastros com milhares de clientes e, sempre que possível,
mantemos os códigos. Em geral, se não houver como identificar as lojas no
sistema legado, colocamos todos os cadastros importados como se tivessem
sido criados na Matriz, que quase sempre é o servidor com ID 1.

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs.

Em 4 de março de 2010 16:43, Tarcísio Sassara
sassara.tarci...@gmail.comescreveu:

 Em 4 de março de 2010 16:00, Alexsander Rosa
 alexsander.r...@gmail.com escreveu:
  Neste cenário, cada servidor tem suas (poucas) SEQUENCES independentes
  (estão fora da replicação) e as PK de algumas tabelas são chaves
 compostas
  que incluem a coluna id_servidor. Os clientes acabam recebendo um
 código
  que costuma ser exibido no formato 9502/1 (código 9502 do servidor 1) e
 os

 Talvez seja melhor pensar em UUIDs.
 http://en.wikipedia.org/wiki/Universally_Unique_Identifier

 --
 Tarcisio F. Sassara



-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

Claro que não detona, são meras chaves compostas -- e com apenas DUAS
colunas. Um exemplo pior de chave composta é o da tabela dos cupons fiscais,
cuja PK tem quatro colunas (data, nº do ecf, nº do cupom e nº da loja),
todas chaves NATURAIS. Os próprios equipamentos fiscais geram estes dados.

Em 4 de março de 2010 18:26, Tarcísio Sassara
sassara.tarci...@gmail.comescreveu:

 Em 4 de março de 2010 16:53, Alexsander Rosa
 alexsander.r...@gmail.com escreveu:
  Sim, tudo é replicado para todos os servidores (exceto as sequences).
  Provavelmente existem pessoas 9502/2, 9502/16, 9502/101...

 Não detona relatórios essas duplicidades?
 Relatórios do tipo Ranking podem mostrar resultados bem diferentes do real.


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

2010-03-05 Por tôpico Alexsander Rosa

Em 4 de março de 2010 17:40, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com:
  Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs.

 Mór di quê?


Acho que as desvantagens superam as vantagens.


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

2010-03-05 Por tôpico Alexsander Rosa

Pra mim a única vantagem é poder gerar UUID fora do banco sem risco
significativo de colisão. Aliás, o fato de não haver 100% de garantia de que
não haverá JAMAIS uma colisão no longo prazo (imagine dezenas de anos em
centenas de filiais com milhares de transações por segundo) é uma
desvantagem. Qualquer probabilidade maior que 0% pode sempre acontecer -- e
Murphy nos garante que VAI acontecer. E o pior: quando houver uma colisão,
se o UUID não for UNIQUE ninguém ficará sabendo...

Outras desvantagens:
- dificulta o DEBUG (e eventuais auditorias),
Imagine ativar o log_statement = mod e acompanhar o resultado. Imagine
tentar rastrear o que um determinado usuário fez num dia e hora específicos
olhando os SQL que ele gerou no período. Sabemos que pode-se modelar a
auditoria, mas os negócios evoluem e o que se quer monitorar hoje é
diferente do que se monitorava ontem. Arquivar o SQL é uma garantia de
poder buscar coisas do passado, quando não se gravava a trilha de auditoria
que se grava hoje.

- ocupa BEM mais espaço em disco/memória que integer
Uma UUID ocupa 128 bits. Um inteiro ocupa 32 bits. Em alguns casos pode-se
usar até smallint, que ocupa 16 bits. Numa tabela que represente um
relacionamento N x N com apenas duas colunas, pode-se ter um pulo de 4 (dois
smallint) para 32 bytes (dois UUID) por tupla. Os índices também sofrem um
impacto significativo. Nunca gostei do argumento memória é barata.

- não pode ser usada em comunicação verbal.
Imagine uma atendente de call center passando uma UUID para o cliente anotar
como número da transação. Se eu tiver que usar uma sequence pra gerar este
número da transação, o uso de UUID perde todo o sentido.

Em 5 de março de 2010 10:17, Dickson S. Guedes lis...@guedesoft.netescreveu:

 Em 5 de março de 2010 09:30, Alexsander Rosa
 alexsander.r...@gmail.com escreveu:
 
  Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.com
  escreveu:
 
  2010/3/4 Alexsander Rosa alexsander.r...@gmail.com:
   Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs.
 
  Mór di quê?
 
 
  Acho que as desvantagens superam as vantagens.

 Em sua opinião quais seriam?

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Localizar determinado caracter

2010-03-09 Por tôpico Alexsander Rosa

Isso é problema de encoding. Provavelmente caracteres LATIN1 num banco UTF-8
ou vice-versa.

Em 9 de março de 2010 16:18, Danilo Gomes [PGOpen] 
danilo.go...@pgopen.com.br escreveu:

 É possível localizar determinado caracter nos registros de uma tabela?

 Exemplo: em minha tabela, os registros estão da seguinte forma: Promo��o.
 (é isso mesmo, interrogação dentro de um triângulo).

 o certo seria Promoção, ou seja, existe algum comando que eu execute e
 retorne todos os registros que contenham �.

 Agradeço desde já a todos pela colaboração.





-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Histórico de Atualizações

2010-03-09 Por tôpico Alexsander Rosa

Eu uso triggers que armazenam as colunas necessárias (no meu caso, são
valores monetários) numa tabela. Tenho colunas como datahora (timestamp),
tabela/coluna (2 x varchar); e valor anterior/novo (2 x numeric), ID do
usuário que alterou, etc. Fica uma tabela única com todas as alterações que
pode ser facilmente pesquisada.

Em 9 de março de 2010 17:22, Alipio Dantas alipiodan...@gmail.comescreveu:

 Srs.

 Preciso manter um histórico de atualizações em determinadas tabelas do
 banco, ou seja quando um registro for alterado, ser mantido também o valor
 anterior.

 Pensei em replicar os dados em uma mesma tabela, o que não é legal, a
 tabela ficaria com um volume de informações que não é acessado com
 frequencia.

 Pensei em clonar a view dentro do banco e inserir nas tabelas referentes
 as linhas atualizadas com a data de atualização. Pra isso o ideal seria uma
 triger que fizesse este procedimento quando um dado for alterado. O problema
 é que não sei por onde começar.



 Alguém poderia me indicar um caminho?

 Obrigado.



 --
 Alípio Dantas da Silva
 Secretaria de Desenvolvimento Urbano do Estado da Bahia
 Coordenação de Informações Geográficas Urbanas - CGI


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] MAC placa de rede

2010-03-11 Por tôpico Alexsander Rosa

Anti-pirataria?

Em 11 de março de 2010 17:08, Marcelo Costa marcelojsco...@gmail.comescreveu:



 2010/3/11 Antonio Cesar cgce...@bol.com.br

 Pessoal o postgresql possui um função que retorne o MAC da placa de do
 servidor?



 hãm (como diria o Leo)



 --
 Marcelo Costa
 www.marcelocosta.net
 -
 “You can't always get what you want”,

 Doctor House in apology to Mike Jagger

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Distancia entre dusa cidade

2010-06-18 Por tôpico Alexsander Rosa

Se você aplicar um Pitágoras terá um ângulo na hipotenusa; converta 
este ângulo em km, de acordo com a curvatura da Terra, e terá a 
distância em km.


Antonio Cesar escreveu:

Boa terde pessoal!

Estou precisando calcular a distancia emtre duas cidade com base em 
longitude e latitude alguem tem uma funçao.

--

Atenciosamente,


  **Cesar** Soares**
  Programador  (75)  8839-2381




--
Alexsander da Rosa
Twitter: @alexrosa


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

Re: [pgbr-geral] Número de conexões

2010-06-22 Por tôpico Alexsander Rosa

Acho melhor usar client_addr para contar os usuários, porque se um mesmo 
usuário (no mesmo IP) abrir 4 conexões serão 4 procpids diferentes com o 
mesmo client_addr.


MarceloG escreveu:

Olá amiguinho,
Se você usa diversos usuários para conexão, veja isso:

SELECT DISTINCT(usename) FROM pg_stat_activity WHERE datname = 
'*minha_base_de_dados*'


Se você usa usuário único para diversas conexões, veja isso:

SELECT COUNT(procpid) FROM pg_stat_activity WHERE datname = 
'*minha_base_de_dados*'


MarceloG!

Em 22/06/2010 11:57, Fabrízio de Royes Mello escreveu:


Em 22 de junho de 2010 10:30, Jesus Rodrigues 
jesusrodrigu...@gmail.com mailto:jesusrodrigu...@gmail.com escreveu:



Logicamente, alterei para o nome da minha base de dados.


Perfeito...
 


Refazendo a pergunta utilizando SELECT count(*) FROM
pg_stat_activity WHERE datname = '*minha_base_de_dados*' obtive
mais de uma conexão. Entretanto, havia apenas um cliente sql
manager conectado no banco. Nesse caso era para ter retornado
apenas 1 ou estou enganado?


Será que esse seu cliente sql manager não abre mais de uma conexão 
com a base de dados??? 


Minha sugestão seria:

1) Fechar o teu SQL Manager e qualquer aplicacao que realize conexao 
com esse seu backend

2) Utilizar o psql para conectar com o backend e rodar a query em questao
 
Se mesmo assim existir mais de uma conexão com a tua base de dados 
então provavelmente elas estão perdidas...


Cordialmente,

--
Fabrízio de Royes Mello
 Blog sobre TI: http://fabriziomello.blogspot.com


--
Alexsander da Rosa
Twitter: @alexrosa


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

Re: [pgbr-geral] Divisão de módulos do ERP em Esqu emas...

2010-07-02 Por tôpico Alexsander Rosa

Pode haver um esquema geral que tem as tabelas básicas e essenciais, por
exemplo.
Na maioria das vezes dá pra identificar estas tabelas, os demais se olha
caso a caso.
Usando junto com o search_path conforme lembrou o Fabrizio, pode ficar
bom.

Em 1 de julho de 2010 20:24, Mozart Hasse mozart.ha...@usa.net escreveu:

 Olá Olavo,

 A divisão em schemas parece interessante porque realmente divide as tabelas
 em grupos. À medida que seu modelo cresce (e nem precisa chegar nas 2000
 tabelas, com 1000 já se tem problemas), o que costuma aparecer são tabelas
 compartilhadas por diversos módulos. Não importa em que módulo você as
 coloque, sempre terá quem interprete que ela deveria estar em outro lugar.
 Pior ainda quando mudam seus requisitos e começam a sobrar motivos para
 mudá-la de um módulo para o outro, gerando um retrabalho absurdo por um
 benefício questionável.
 Mudar a tabela de lugar em visões de modelo dentro da sua ferramenta de
 modelagem, contudo, é uma tarefa simples e sem consequências mais sérias,
 pois você poderá colocar cópias dela em quantos modelos convier.
 Devido a isso, sou mais favorável a largar mão dessa história de misturar
 schema com documentação e colocar todas as tabelas num schema só. Facilita
 enormemente o desenvolvimento e montagem das consultas, além de facilitar
 *muito* a manutenção.
 Talvez alguém cogite a idéia de controlar a segurança dos módulos por
 esquema, porém acho pouco provável que um esquema assim atenda a qualquer
 cliente por causa das tabelas compartilhadas e potenciais problemas quando
 uma tabela mudar de módulo.

 Minha sugestão, portanto, é: use um schema só e seja feliz.

 Atenciosamente,

 Mozart Hasse



 From: C.P.D. - T.I. MoRHena c...@morenarh.com.br
 To: pgbr-geral@listas.postgresql.org.br

 Estou desenvolvendo um ERP e vou comercializá-lo em módulos. Em
 virtude de disponibilizar em módulos, gostaria de separar as tabelas do
 banco de dados por módulo. Seria adequado o uso de esquema neste caso ?
 Ou seja no banco de dados teria esquema como: vendas, faturamento,
 financeiro e para cada esquema suas respectivas tabelas. É uma boa
 prática usar deste artifício ?

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

Eu desenvolvi uma replicação que está sendo usada pelos meus clientes (ex:
www.casadopapel.com.br), mas meu ERP foi projetado levando isto em
consideração. Há tabelas globais onde apenas um servidor pode gravar -- a
aplicação não deixa os usuários das lojas gravarem em tabelas como
alíquotas de ICMS ou lista de UF. As demais são tabelas locais e todas
possuem como parte da chave uma coluna número da loja; por exemplo o
pedido 1234 feito na loja 7 fica com número 1234/7.

Meu ERP usa um framework de persistência que grava numa tabela separada
todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON das
lojas envia estes comandos para o servidor central (a topologia é estrela)
de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as lojas
todas as atualizações que recebeu, também minuto a minuto.

Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda
l...@fricke.com.brescreveu:

 Bom dia pessoal,

 Estamos implementando uma replicação (sincronização) de bases com o
 Postgres,
 Testamos o Pgpool mas ele não está funcionando legal com nossa
 aplicação, tem outro produto que faça isso melhor?

 --
 Lucas Lima

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem
gente que acha aceitável deixar os funcionários de braços cruzados
informando aos clientes o sistema está fora do ar, mas no comércio o furo
é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes
foram roubados várias vezes seguidas, logo após a reposição. Somente quando
a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais
de alguns dias online.

Se a replicação multi-master tiver sido prevista desde o início, a
integridade pode ser mantida dentro de alguma tolerância se algumas
restrições forem usadas. Existem várias coisas que a aplicação não permite
fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não
dá pra pensar que uma replicação multi-master vai estar com os dados 100%
iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação
feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias

  Eu desenvolvi uma replicação que está sendo usada pelos meus clientes
 (ex:
  www.casadopapel.com.br), mas meu ERP foi projetado levando isto em
  consideração. Há tabelas globais onde apenas um servidor pode gravar --
  a
  aplicação não deixa os usuários das lojas gravarem em tabelas como
  alíquotas de ICMS ou lista de UF. As demais são tabelas locais e
  todas
  possuem como parte da chave uma coluna número da loja; por exemplo o
  pedido 1234 feito na loja 7 fica com número 1234/7.
 
  Meu ERP usa um framework de persistência que grava numa tabela separada
  todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON
  das
  lojas envia estes comandos para o servidor central (a topologia é
 estrela)
  de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as
  lojas
  todas as atualizações que recebeu, também minuto a minuto.
 


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

Sabia que a legislação exige que os caixas com ECF continuem emitindo cupons
mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o cabo de
rede, o PDV tem que continuar funcionando. Isto existe para evitar que
sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de que
o sistema está fora do ar. A integridade vai pro espaço por exigência da
legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc.

Todas as grandes redes de supermercados possuem bancos de dados locais, um
em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por
exigência legal -- possuem dados locais. Neste contexto, pensar em hospedar
em Data Center não faz o menor sentido: o Walmart, por exemplo, recebe
dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um
atraso de um minuto está de bom tamanho.

Em 8 de julho de 2010 15:09, Ralf Schlindwein ralfoa...@gmail.comescreveu:

 Faça uma relação hospedar em um DataCenter confiável X valor funcionários
 parados.
 Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e
 Servidor e fique feliz somente gerenciando a sua TI.





 Em 8 de julho de 2010 15:02, Alexsander Rosa 
 alexsander.r...@gmail.comescreveu:

 Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem
 gente que acha aceitável deixar os funcionários de braços cruzados
 informando aos clientes o sistema está fora do ar, mas no comércio o furo
 é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes
 foram roubados várias vezes seguidas, logo após a reposição. Somente quando
 a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais
 de alguns dias online.

 Se a replicação multi-master tiver sido prevista desde o início, a
 integridade pode ser mantida dentro de alguma tolerância se algumas
 restrições forem usadas. Existem várias coisas que a aplicação não permite
 fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não
 dá pra pensar que uma replicação multi-master vai estar com os dados 100%
 iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação
 feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

 Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu já
disse: não dá pra pensar que uma replicação multi-master vai estar com os
dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
outra.

Em 8 de julho de 2010 17:15, fabi...@wolaksistemas.com.br escreveu:


 PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar
 independente. O que me referi foi a forma que você implementou o sistema.

 Att,
 Fabiano Machado Dias




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

2010-07-09 Por tôpico Alexsander Rosa

Vamos por partes.

Em 8 de julho de 2010 20:51, fabi...@wolaksistemas.com.br escreveu:

 Treços do teu email:

 Há tabelas globais onde apenas um servidor pode gravar - Se esse
 servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a
 aplicação em um data center, ou seja se você depende de um central não há
 porque ter as locais afinal não vai funcionar sem as globais não é? Ou
 entendi errado?


Você entendeu errado. Estas tabelas globais são replicadas normalmente,
mas as filiais não têm permissão de escrita em suas cópias. São tabelas cuja
manutenção é centralizada -- como por exemplo, estado da federação. Se o
Congresso criar um novo estado, digamos o Pará do Sul (PS), somente um
usuário logado no servidor central (e devidamente autorizado) vai poder
criar este registro. Esta tabela não tem uma coluna id do servidor como
parte da chave primária, que no caso seria obviamente a sigla do estado,
PS. Se a empresa começar a aceitar pagamentos em tampinhas de garrafa, o
registro tampinha de garrafa com sigla e chave primária TPG poderá ser
criada apenas na central.



 Meu ERP usa um framework de persistência - Opção de cada desenvolver, eu
 por experiência recomendo passar longe desse tipo de coisa. Tomara que não
 acontece com você mas o dia que resolver dar pau, reze.


Eu mesmo desenvolvi o framework de persistência, além de uma ferramenta de
engenharia reversa e um gerador de código. O framework está bastante
otimizado (afinal, o código tem mais de 5 anos de uso em produção) e os
comandos gerados por ele foram bem depurados, não há pesquisas
desnecessárias nem exigência de OID. Ele atende perfeitamente a imensa
maioria dos casos, mas para aquelas situações onde um SQL feito à mão é
melhor existe suporte a views e stored procedures.


 grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE -
 Já citado antes a questão da integridade, mas como você falou dependendo
 do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista.
 Hoje já temos infra suficiente para manter um link decente e se a desculpa
 for a rede que pode cair, vide a NFe e o SPED.


Ainda não vi no mercado links perfeitos. Por outro lado já vi um Centro de
Distribuição ficar mais de 24h sem Internet porque os fios de cobre de todos
os links foram roubados. Não vejo como um servidor centralizado pode ser
melhor, não imagino explicar para o cliente que um processo vital como o
recebimento de mercadorias em uma filial tem que ficar parado, deixando
faltar produtos na prateleira, porque a rede está fora do ar. No caso da NFe
é diferente: o seu BD está funcionando, seu processo continua, apenas o
servidor da Fazenda que está indisponível. Imagine se cada vez que fosse
preciso emitir uma NFe em contingência, toda a empresa do cliente parasse.
Isso é o que acontece quando você roda aplicações vitais em data centers
remotos.


 um processo que roda no CRON das lojas envia estes comandos para o
 servidor central - No meu ponto de vista não é uma solução elegante.

 Elegância é subjetiva.


 O servidor central, por sua vez, envia para todas as lojas todas as
 atualizações que recebeu, também minuto a minuto. - Você centraliza,
 distribui e centraliza novamente. Se o teu servidor precisa mandar as
 atualização para as filiais porque não centraliza tudo de uma vez e deixa
 só o PDV de fora.

 O objetivo é manter os servidores idênticos: poucos minutos depois do final
do expediente, todos estão iguais. Além disso, uma filial pode querer saber
onde tem alguma mercadoria: por exemplo, pode chegar um cliente pedindo uma
coisa que está em falta naquela loja mas tem disponível em outra.



 São apenas ponderações baseado no email que você mandou, não estou dizendo
 que está errado, apenas que pode ser melhor e mais confiável.

 Abraço,
 Fabiano Machado Dias


 Agradeço seus comentários.



  Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu
 já
  disse: não dá pra pensar que uma replicação multi-master vai estar com os
  dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
  modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
  outra.
 


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Delete *

2010-07-22 Por tôpico Alexsander Rosa

Se o usuário tem username/senha para logar direto no banco, tendo GRANT
suficiente ele pode dar até um DROP DATABASE. Acho muito perigoso deixar
usuários com permissão para mexer direto no banco.

Em 22 de julho de 2010 11:38, JotaComm jota.c...@gmail.com escreveu:

 Olá,

 Em 22 de julho de 2010 11:25, Candido Vieira da Silva Neto cvieira.br@
 gmail.com escreveu:

 Vinicius, existe o controle de transacoes para evitar 'acidentes'.

 BEGIN e COMMIT/SAVEPOINT/ROLLBACK

 On 7/22/10, Vinicius Marconi Vasconcelos Berni
 vinicius.marc...@gmail.com wrote:
  Não permitir que seja executado delete na base de dados sem fornecer
  clausula where,  quero fazer isto para evitar 'acidentes'.
 
  Ex.: delete from pessoa -  Esta query não deve ser permitida.
 
 delete from pessoa where id=2 - Esta será permitida


 Uma pergunta. As exclusões serão feitas pela aplicação ou o usuário pode ir
 manualmente na base e executar um comando delete em qualquer tabela?

 Que tal criar uma função simples para fazer a deleção dos usuários se este
 procedimento for executado pela aplicação, com por exemplo:

 CREATE OR REPLACE FUNCTION exclusao(INTEGER)

 RETURNS BOOLEAN AS $$

 BEGIN

 DELETE FROM tabela WHERE campo_chave=$1;

 IF FOUND THEN

 RAISE NOTICE 'O registro % foi excluido.',$1;

 RETURN TRUE;

 END IF;

 RAISE NOTICE 'O registro % não foi encontrado.',$1;

 RETURN FALSE;

 END;

 $$ LANGUAGE PLPGSQL RETURNS NULL ON NULL INPUT;


  
 
 
  Em 22 de julho de 2010 11:12, JotaComm jota.c...@gmail.com escreveu:
 
  Olá,
 
  Em 22 de julho de 2010 09:31, Vinicius Marconi Vasconcelos Berni 
  vinicius.marc...@gmail.com escreveu:
 
  Olá.
 
  Existe uma maneira de restringir 'delete' sem cláusula 'where' ?
 
 
  Como assim? O que exatamente você deseja?
 
 
  Desde já agradeço. No aguardo.
 
  --
  Ass.:
Vinicius Marconi Vasconcelos  Berni
 51 - 96608087
 51 - 32482071
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
  []s
  --
  JotaComm
  http://jotacomm.wordpress.com
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
  --
  Ass.:
Vinicius Marconi Vasconcelos  Berni
 51 - 96608087
 51 - 32482071
 
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como dizer ao banco que a string é o nome da coluna

2010-07-26 Por tôpico Alexsander Rosa

Tem certeza que a modelagem está correta?

Em 26 de julho de 2010 11:52, Heloisa Fernanda helois...@yahoo.com.brescreveu:

 Bom dia!

 Estou precisando de uma ajuda no seguinte:

 Tenho uma tabela onde eu cadastro as perguntas para questionarios
 parametrizaveis--

 CREATE TABLE base_question
 (
  question_id serial NOT NULL,
  question text);

 Tenho outra tabela que é gerada automaticamente e guarda as respostas:

 CREATE TABLE ques_69_social--
 (
  c377 smallint,
  c585 integer,
  c384 character varying(15));

 Onde por exemplo: c377 corresponde a 'c' + question_id (377) da tabela
 base_question.

 Preciso executar o seguinte SQL:

 SELECT
question_id,
question,
(SELECT ('c'||a.question_id) FROM ques_69_social)
 FROM
base_question a;

 Não sei como dizer ao postgres para entender ('c'||a.question_id) como nome
 da coluna.

 Alguem tem ideia de como fazer isso?



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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

2010-07-28 Por tôpico Alexsander Rosa

Serve um SELECT pg_relation_size('history') / tamanho do registro ?

Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
moni...@stf.jus.brescreveu:

  Olá!



 Será que é possível otimizar a seguinte consulta, executada de hora em hora
 no banco:



 select count(*) from history;



 Essa consulta costuma ter uma duração que varia de  32000.000 ms a
 62262.751 ms  conforme o horário em que é executada.



 A tabela history possui em média *87 milhões* de registros.

 É uma tabela que sofre muito insert/update/delete.

 Faço analyze e reindexação semanalmente.



 Estou utilizando postgresql 8.4.4



 A tabela tem a seguinte estrutura e índice:



 CREATE TABLE history

 (

   itemid bigint NOT NULL DEFAULT (0)::bigint,

   clock integer NOT NULL DEFAULT 0,

   value numeric(16,4) NOT NULL DEFAULT 0.

 )

 WITH (OIDS=TRUE);



 -- Index: history_1



 CREATE INDEX history_1  ON.history

   USING btree  (itemid, clock);





 *Mônica***





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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
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á para armazenar arquivos XML?

2010-08-23 Por tôpico Alexsander Rosa

Em outras palavras: se for preciso trabalhar com as informações dentro deste
XML (acessar, alterar, etc) então o melhor é usar o tipo de dados XML. Se o
objetivo é apenas armazenar para depois enviar para algum lugar, sem fazer
processamento algum, um tipo binário ou text pode servir. Em teoria, o ideal
seria usar o tipo nativo mesmo assim, mas pode ser que o XML esteja
formatado de alguma maneira não padronizada que uma outra aplicação pode
estar esperando, ou algo do gênero. Nem sempre o IDEAL da teoria serve para
a realidade -- lembram dos CNPJ dos órgãos públicos?

Em 23 de agosto de 2010 15:16, Euler Taveira de Oliveira
eu...@timbira.comescreveu:

 Celso escreveu:
  eu gravo em um campo do tipo Text.
 
 O tipo de dado xml foi criado exatamente para este propósito; se é
 documento
 xml então utilize o tipo xml.


 --
  Euler Taveira de Oliveira
  http://www.timbira.com/
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] [OFF] Verdades pouco conhecidas s obre programação

2010-08-25 Por tôpico Alexsander Rosa

http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

My experience as a programmer has taught me a few things about writing
software. Here are some things that people might find surprising about
writing code:

- A programmer spends about 10-20% of his time writing code, and most
programmers write about 10-12 lines of code per
dayhttp://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projectsthat
goes into the final product, regardless of their skill level. Good
programmers spend much of the other 90% thinking, researching, and
experimenting to find the best design. Bad programmers spend much of that
90% debugging code by randomly making changes and seeing if they work.
“A great lathe operator commands several times the wage of an average
lathe operator, but a great writer of software code is worth 10,000 times
the price of an average software writer.” –Bill Gates
- A good programmer is ten times more productive than an average
programmer. A great programmer is 20-100 times more productive than the
average. This is not an
exaggerationhttp://www.devtopics.com/programmer-productivity-the-tenfinity-factor/–
studies since the 1960′s have consistently shown this. A bad
programmer is
not just unproductive – he will not only not get any work done, but create a
lot of work and headaches for others to fix.
- Great programmers spend very little of their time writing code – at
least code that ends up in the final product. Programmers who spend much of
their time writing code are too lazy, too ignorant, or too arrogant to find
existing solutions to old problems. Great programmers are masters at
recognizing and reusing common patterns. Good programmers are not afraid to
refactor (rewrite) their code constantly to reach the ideal design. Bad
programmers write code which lacks conceptual integrity, non-redundancy,
hierarchy, and patterns, and so is very difficult to refactor. It’s easier
to throw away bad code and start over than to change it.
- Software obeys the laws of entropy, like everything else. Continuous
change leads to software rot, which erodes the conceptual integrity of the
original design. Software rot is unavoidable, but programmers who fail to
take conceptual integrity into consideration create software that rots so so
fast that it becomes worthless before it is even completed. Entropic failure
of conceptual integrity is probably the most common reason for software
project failure. (The second most common reason is delivering something
other than what the customer wanted.) Software rot slows down progress
exponentially, so many projects face exploding timelines and budgets before
they are killed.
- A 2004 study found
thathttp://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishmost
software projects (51%) will fail in a critical aspect, and 15% will
fail totally. This is an improvement since 1994, when 31% failed.
- Although most software is made by teams, it is not a democratic
activity. Usually, just one person is responsible for the design, and the
rest of the team fills in the details.
- Programming is hard work. It’s an intense mental activity. Good
programmers think about their work 24/7. They write their most important
code in the shower and in their dreams. Because the most important work is
done away from a keyboard, software projects cannot be accelerated by
spending more time in the office or adding more people to a
projecthttp://en.wikipedia.org/wiki/Brooks%27s_law
.

--
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Re: [pgbr-geral] RES: RES: RES: Lentidão em se rvidor de dados

2010-08-25 Por tôpico Alexsander Rosa

Sua CPU está desacelerando para se auto-proteger de um super aquecimento.
Verifique os coolers e a refrigeração em geral.

Em 25 de agosto de 2010 18:05, marlon david de souza
mar...@sysmo.com.brescreveu:

  No *dmesg* achei estranho a seguinte mensagem:



 *temperature above threshold. cpu clock throttled*



 Essa mensagem dá em vários núcleos.

 Não sei dizer se isso é normal acontecer.



 *De:* pgbr-geral-boun...@listas.postgresql.org.br [mailto:
 pgbr-geral-boun...@listas.postgresql.org.br] *Em nome de *Aldrey Galindo
 *Enviada em:* quarta-feira, 25 de agosto de 2010 17:21
 *Para:* Comunidade PostgreSQL Brasileira
 *Assunto:* Re: [pgbr-geral] RES: RES: Lentidão em servidor de dados



 Marlon,

Nos logs do Banco não mostra nada?
Em geral no Linux, quando é erro de hardware um 'dmesg' já mostra algo.

 Abraços,
 Aldrey Galindo





-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] ALTER SEQUENCE foo START no 8.3.11 - bug?

2010-08-26 Por tôpico Alexsander Rosa

O PostgreSQL 8.4 suporta os comandos ALTER SEQUENCE ... START e RESTART:
http://www.postgresql.org/docs/8.4/static/sql-altersequence.html

O PostgreSQL 8.3 tem apenas o RESTART:
http://www.postgresql.org/docs/8.3/static/sql-altersequence.html

Em teoria, um comando ALTER SEQUENCE foo START no 8.3.11 deveria dar erro
de sintaxe ou coisa parecida, certo? No entanto o servidor 8.3.11 não
apenas ACEITOU o comando que não consta do manual, mas EXECUTOU ERRADO.
Aparentemente ele interpretou como um RESTART e reiniciou a sequence! Isto
não seria um bug?

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ALTER SEQUENCE foo START no 8.3.11 - bug?

2010-08-26 Por tôpico Alexsander Rosa

Conversando no canal #postgresql eu descobri que a versão 8.3 tem, sim, o
START -- então aparentemente isto é um BUG mesmo. A documentação online do
8.3 não mostra o comando, mas ele é suportado. Talvez por isto ninguém tenha
visto ainda este bug. Estou conversando com o pessoal pra ver se faço um bug
report, mas fica o recado.

Em 26 de agosto de 2010 15:58, Alexsander Rosa
alexsander.r...@gmail.comescreveu:

 O PostgreSQL 8.4 suporta os comandos ALTER SEQUENCE ... START e RESTART:
 http://www.postgresql.org/docs/8.4/static/sql-altersequence.html

 O PostgreSQL 8.3 tem apenas o RESTART:
 http://www.postgresql.org/docs/8.3/static/sql-altersequence.html

 Em teoria, um comando ALTER SEQUENCE foo START no 8.3.11 deveria dar erro
 de sintaxe ou coisa parecida, certo? No entanto o servidor 8.3.11 não
 apenas ACEITOU o comando que não consta do manual, mas EXECUTOU ERRADO.
 Aparentemente ele interpretou como um RESTART e reiniciou a sequence! Isto
 não seria um bug?

 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ALTER SEQUENCE foo START no 8.3.11 - bug?

Se você reparar, o START mudou o valor da sequence, o que não deveria ter
acontecido.

Em 26 de agosto de 2010 23:20, Marcelo Costa marcelojsco...@gmail.comescreveu:



 2010/8/26 Alexsander Rosa alexsander.r...@gmail.com

 Conversando no canal #postgresql eu descobri que a versão 8.3 tem, sim, o
 START -- então aparentemente isto é um BUG mesmo. A documentação online do
 8.3 não mostra o comando, mas ele é suportado. Talvez por isto ninguém tenha
 visto ainda este bug. Estou conversando com o pessoal pra ver se faço um bug
 report, mas fica o recado.


 Não vi o BUG que vc relatou a única coisa que detectei é que o manual não
 cita o START na versão 8.3.

 Testei num 8.3.9 e funcionou normalmente

 # create table teste (id serial, nome varchar(50), data_nascimento date);
 NOTICE:  CREATE TABLE will create implicit sequence teste_id_seq for
 serial column teste.id
 CREATE TABLE


 # select * from teste_id_seq;
  sequence_name | last_value | increment_by |  max_value  |
 min_value | cache_value | log_cnt | is_cycled | is_called

 ---++--+-+---+-+-+---+---
  teste_id_seq  |  1 |1 | 9223372036854775807 |
 1 |   1 |   1 | f | f
 (1 row)

 # alter SEQUENCE teste_id_seq start 2000;
 ALTER SEQUENCE

 # select * from teste_id_seq;
  sequence_name | last_value | increment_by |  max_value  |
 min_value | cache_value | log_cnt | is_cycled | is_called

 ---++--+-+---+-+-+---+---
  teste_id_seq  |   2000 |1 | 9223372036854775807 |
 1 |   1 |   1 | f | f
 (1 row)


 # alter SEQUENCE teste_id_seq restart 1;
 ALTER SEQUENCE

 # select * from teste_id_seq;
  sequence_name | last_value | increment_by |  max_value  |
 min_value | cache_value | log_cnt | is_cycled | is_called

 ---++--+-+---+-+-+---+---
  teste_id_seq  |  1 |1 | 9223372036854775807 |
 1 |   1 |   1 | f | f
 (1 row)

 --
 Marcelo Costa


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ALTER SEQUENCE foo START no 8.3.11 - bug?

Explicando em mais detalhes:

Na versão 8.3 o comando ALTER SEQUENCE tem uma cláusula não-documentada
START que é, na verdade, apenas um alias para RESTART. Ambos exigem um
parâmetro, que é o número para o qual a sequence será reiniciada, e
portanto equivalem a um SELECT setval('foo', valor). Cabe lembrar que a
documentação da versão 8.3 [1] não menciona o START.

Na versão 8.4 isto foi modificado: a cláusula START do ALTER SEQUENCE passou
a modificar o valor do START WITH da sequence, ou seja, o valor que a
sequence vai assumir se for executado um RESTART sem parâmetros (o
parâmetro, que era obrigatório na 8.3, é opcional na 8.4). Este comando,
conforme a documentação da versão 8.4 [2], não modifica o valor da sequence,
apenas configura um futuro RESTART da mesma.

Eu descobri isto rodando um ALTER SEQUENCE ... START em vários servidores
replicados (com versões 8.4 e 8.3), para deixar as bases 100% iguais. Eu
achava que nos servidores 8.3, onde segundo a documentação o START não
existe, daria apenas uma mensagem de erro. Fiquei surpreso ao ver que o
START é um alias para RESTART.

Na minha opinião este comportamento da 8.3 é um bug -- talvez um bug
conhecido. Aparentemente o START WITH está sendo interpretado como RESTART
WITH por engano.

[1] http://www.postgresql.org/docs/8.3/static/sql-altersequence.html
[2] http://www.postgresql.org/docs/8.4/static/sql-altersequence.html

Em 27 de agosto de 2010 10:12, Alexsander Rosa
alexsander.r...@gmail.comescreveu:

 Se você reparar, o START mudou o valor da sequence, o que não deveria ter
 acontecido.

 Em 26 de agosto de 2010 23:20, Marcelo Costa 
 marcelojsco...@gmail.comescreveu:



 2010/8/26 Alexsander Rosa alexsander.r...@gmail.com

 Conversando no canal #postgresql eu descobri que a versão 8.3 tem, sim, o
 START -- então aparentemente isto é um BUG mesmo. A documentação online do
 8.3 não mostra o comando, mas ele é suportado. Talvez por isto ninguém tenha
 visto ainda este bug. Estou conversando com o pessoal pra ver se faço um bug
 report, mas fica o recado.


 Não vi o BUG que vc relatou a única coisa que detectei é que o manual não
 cita o START na versão 8.3.

 Testei num 8.3.9 e funcionou normalmente

 # create table teste (id serial, nome varchar(50), data_nascimento date);
 NOTICE:  CREATE TABLE will create implicit sequence teste_id_seq for
 serial column teste.id
 CREATE TABLE


 # select * from teste_id_seq;
  sequence_name | last_value | increment_by |  max_value  |
 min_value | cache_value | log_cnt | is_cycled | is_called

 ---++--+-+---+-+-+---+---
  teste_id_seq  |  1 |1 | 9223372036854775807 |
 1 |   1 |   1 | f | f
 (1 row)

 # alter SEQUENCE teste_id_seq start 2000;
 ALTER SEQUENCE

 # select * from teste_id_seq;
  sequence_name | last_value | increment_by |  max_value  |
 min_value | cache_value | log_cnt | is_cycled | is_called

 ---++--+-+---+-+-+---+---
  teste_id_seq  |   2000 |1 | 9223372036854775807 |
 1 |   1 |   1 | f | f
 (1 row)


 # alter SEQUENCE teste_id_seq restart 1;
 ALTER SEQUENCE

 # select * from teste_id_seq;
  sequence_name | last_value | increment_by |  max_value  |
 min_value | cache_value | log_cnt | is_cycled | is_called

 ---++--+-+---+-+-+---+---
  teste_id_seq  |  1 |1 | 9223372036854775807 |
 1 |   1 |   1 | f | f
 (1 row)

 --
 Marcelo Costa


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como usar o pgcrypto

Lembrando que o md5 não criptografa dados, apenas faz um digest deles.

Em 27 de agosto de 2010 12:18, JotaComm jota.c...@gmail.com escreveu:

 Olá,

 Em 27 de agosto de 2010 12:10, Beto Lima betol...@gmail.com escreveu:

 Olá, alguém saberia dizer como usar o pgcrypto?
 A intenção é gravar dados criptografados em uma tabela.
 Ou teria alguma outra função direta no banco?


 Depende muito, por exemplo, o PostgreSQL tem a função md5 por exemplo para
 criptografar os dados.

 Exemplo:

 postgres=# SELECT md5('teste');
md5
 --
  698dc19d489c4e4db73e28a713eab07b
 (1 row)



 Grato
 Beto Lima

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



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ALTER SEQUENCE foo START no 8.3.11 - bug?