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

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

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

[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 

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

[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 

> Olá,
>
> 2010/1/4 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.
>>
>
> 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] Qual estrutura utilizar?

[Alexsander Rosa]

Então devo fazer uma chave composta com CNPJ+INEP e deixar NULL no campo
"codigo_inep" em 99% dos registros? Escolas são apenas uma pequena parte do
problema, outras secretarias em outras esferas apresentam o mesmo problema.
Outros exemplos: Correios, CEEE, SESC, etc. Parece mais um caso onde a
emenda é pior que o soneto.

2010/1/4 Leonardo Cezar 

> 2010/1/4 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.
>
> 
>
> Utilize o código INEP [1] ... ;-) que naturalmente deveria ser a chave
> de instituição educional.
>
> 1) inep.gov.br
>
> 
>
> -Leo
> --
>

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

[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 

>
>
> 2010/1/4 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.
>>
>>
> 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?

[Alexsander Rosa]

Comentários no texto.

2010/1/7 Leandro DUTRA 

> 2010/1/4 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.
>
> 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?

[Alexsander Rosa]

Que bom que acabamos nos entendendo...

2010/1/7 Leandro DUTRA 

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

[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 

>  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 
> *To:* Comunidade PostgreSQL Brasileira
> *Sent:* Tuesday, January 12, 2010 3:22 PM
> *Subject:* Re: [pgbr-geral] Tamanho das tabelas!
>
> Olá,
>
> 2010/1/12 Glênio Côrtes Himmen 
>
>> 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!

[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 

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

[Alexsander Rosa]

Linux rulez!
FLAME MODE ON

2010/1/21 Marcos André 

> 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

[Alexsander Rosa]

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 

> 2010/1/21 Jurandir Dallabeneta :
> > 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

[Alexsander Rosa]

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 

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

[Alexsander Rosa]

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

2010/1/22 JotaComm 

> Olá, Alexander
>
> 2010/1/22 Alexsander Rosa 
>
>> 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 
>>
>>
>>> 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

[Alexsander Rosa]

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 

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

[Alexsander Rosa]

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 

> 2010/1/20 Vinicius Santos :
> >> 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

[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

[Alexsander Rosa]

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

[Alexsander Rosa]

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

[Alexsander Rosa]

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

> Em 4 de março de 2010 13:28, Alexsander Rosa
>  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

[Alexsander Rosa]

Leandro:

Em 4 de março de 2010 16:30, Leandro DUTRA
escreveu:

> 2010/3/4 Alexsander Rosa :
>
> > 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

[Alexsander Rosa]

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

Em 4 de março de 2010 16:43, Tarcísio Sassara
escreveu:

> Em 4 de março de 2010 16:00, Alexsander Rosa
>  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

[Alexsander Rosa]

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

> Em 4 de março de 2010 16:53, Alexsander Rosa
>  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

[Alexsander Rosa]

Em 4 de março de 2010 17:40, Leandro DUTRA
escreveu:

> 2010/3/4 Alexsander Rosa :
> > 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

[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 escreveu:

> Em 5 de março de 2010 09:30, Alexsander Rosa
>  escreveu:
> >
> > Em 4 de março de 2010 17:40, Leandro DUTRA 
> > escreveu:
> >>
> >> 2010/3/4 Alexsander Rosa :
> >> > 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

[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

[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 escreveu:

> 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

[Alexsander Rosa]

Anti-pirataria?

Em 11 de março de 2010 17:08, Marcelo Costa escreveu:

>
>
> 2010/3/11 Antonio Cesar 
>
> 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] Pesquisar mes dentro da data

[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

[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 AT&T 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.

[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

[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] Performace baixa com Hibernate

[Alexsander Rosa]

Aqui na empresa, desenvolvemos um OPF (framework de persistência de objetos)
que funciona em conjunto com um Gerador de Código que faz o caminho inverso:
ele parte do modelo de dados e gera o modelo de classes. Na interface o
usuário pode detalhar os relacionamentos entre as classes e fazer mais
alguns ajustes, se necessário, mas o foco está no modelo de dados, não no
modelo de objetos.

O objetivo principal é o ganho de produtividade: o programador pode usar a
feature de "Auto Complete" da IDE, por exemplo, para selecionar
propriedades. Erros em nomes de colunas do BD causam erros de *compilação*,
aumentando a confiabilidade. O FW também permite carregar o resultado de uma
query em uma lista de objetos com propriedades como Count e IndexOf(pk). Nos
casos mais simples usa-se o método QueryByTemplate( ); para os casos mais
incomuns existe a QueryByFreeSql( ).

Havia um flag para ativar o pattern "lazy loading", mas depois de três anos
de uso resolvemos tornar essa opção DEFAULT e removemos o flag, porque a
diferença de performance é monstruosa. Outra coisa que modificamos foi a
carga de colunas binárias, que por default não é feita quando um objeto é
instanciado. Comparando com os SELECT's feitos à mão, na maioria dos casos
não há diferença de performance. O FW tem inclusive um modo de "debug" que
mostra o SQL que foi gerado.

Nosso maior problema é educar o programador... por exemplo, se ele quer
mostrar uma lista de pedidos com os nomes dos clientes, ele *NÃO* deve fazer
uma query na tabela pedidos e depois varrer, dentro do FOR, mandando exibir
o conteúdo de  lista_pedido[i].Cliente.Nome (pois isso irá gerar um SELECT
pra cada pedido), mas SIM fazer uma query em uma view criada especificamente
para este fim. Claro que é muito fácil o cara ir digitando
"lista_pedido[i]." depois usar o "auto complete" para selecionar "Cliente."
e depois "Nome". Mas isso não é nada que não possa ser resolvido com um
pouco de treinamento ou com disposição para contratar profissionais mais
qualificados (e caros). :-)

Em 16/04/08, Leandro DUTRA <[EMAIL PROTECTED]> escreveu:
>
> 2008/4/15, Nâmio Evangelista <[EMAIL PROTECTED]>:
>
> >
> >  Normalmente, problemas como esse acontece quando se tem um programador
> ou
> >  analista desavidado, que acha que o Hibernate é o "rei da cocada
> preta"; que
> >  só basta criar as classes e os seus respectivos arquivos de mapeamente
> que
> >  está tudo tranqüilo.
>
>
> De fato.
>
>
>
> >  Existe muitas maneiras de otimizar o mapeamento das classes. Um estudo
> >  detalhado desta modelagem se faz necessário para obter um ganho de
> >  performance significativo. Tomar os devidos cuidados com relação à
> >  identidade de objetos é de suma importância para não vir a ter
> decepções no
> >  futuro; saber modelar a cardinalidade e a navegabilidade entre as
> >  associações de classes também é primordial.
>
>
> Existe uma maneira muito mais simples: faça-se a modelagem dos dados,
> e o Hibernate (ou o que mais se for usar) que se adapte a isso.
>
> Na minha experiência, 'profissionais Hibernate' dificilmente querem se
> moldar a um modelo de dados são.
>
>
>
> >  O problema que o autor deste artigo está enfrentando, eu também passei,
> >  usando Oracle, quando estava iniciando os trabalhos com Hibernate. A
> >  diferença é que pesquisei bastante antes de sair falando besteiras a
> >  respeito da framework.
>
>
> Que autor, que artigo?  Que besteiras?  Você está respondendo a uma
> dúvida de um colega, que não merece ser tratado desse jeito.
>
>
>
> >  Parto do princípio de que se dentre milhares de pessoas que utilizam
> >  Hibernate (ou NHibernate), apenas uma, duas ou até dez pessoas falam
> >  asneiras desta framework, o problema está no profissional e não na
> >  framework.
>
>
> Primeiro, o que é NHibernate?
>
> Segundo, leve em consideração que ferramentas não existem no vácuo,
> mas têm um caldo de cultura que as acompanham.  A cultura Hibernate é
> francamente hostil à modelagem de dados.
>
>
>
> >  Fico a imaginar como este autor se sairia tendo de usar um
> banco-de-dados
> >  como o Caché, DB4O, ou qualquer outro banco-de-dados orientado a
> objetos.
>
>
> Justiça seja feita, esses SGBDOOs saem-se relativamente bem com a
> estupidez normalmente gerada pelo Hibernate.
>
> Com o contraponto de que são praticamente inúteis para tudo o mais em
> comparação com um SGBD SQL, e que é quase impossível criar outros
> programas para usar a mesma base de dados.  Relatórios, entã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,

Alexsan

Re: [pgbr-geral] Performace baixa com Hibernate

[Alexsander Rosa]

Respondendo no corpo do texto.

Em 17/04/08, Mozart Hasse <[EMAIL PROTECTED]> escreveu:
>
> Alexsander,
>
> > Havia um flag (...). Comparando com os SELECT's feitos à mão, na maioria
>
> > dos casos
> > não há diferença de performance. O FW tem inclusive um modo de "debug"
> que
> > mostra o SQL que foi gerado.
>
>
> Nem todo mundo pode se dar ao luxo de usar uma query mais lenta,
> especialmente
> se ela for feita dúzias de vezes por minuto ou se o otimizador resolver
> ler
> a tabela
> inteira com milhões de registros. O que vocês fazem quando a consulta
> precisa de
> desempenho, fazem à mão? Se toda a consulta que fica lenta precisa ser
> feita
> à mão,
> quanto sobra para fazer automaticamente?


Os comandos feitos à mão foram usados apenas para efeito de comparação. Na
imensa maioria dos casos (algo em torno de 99% dos comandos executados ao
longo de um dia) os códigos SQL gerados pelo Framework são exatamente
idênticos aos que seriam usados se fosse preciso criá-los manualmente. Por
exemplo, ao mexer num cadastro é feito um "UPDATE tabela SET coluna1=valor,
coluna2=valor etc WHERE chave1 = pk1 AND chave2 = pk2 etc" que acaba sendo
padronizado, mesmo fazendo à mão você vai escrever a mesma coisa.

Na imensa maioria das vezes você faz SELECT's pela(s) chave(s) ou através de
pesquisa em poucos campos. Nesses casos o Framework traz facilidade de
uso... por exemplo, para buscar pela(s) chave(s) você pode digitar objXXX,
teclar "ponto" e deixar a IDE mostrar os métodos, depois selecionar
"LocateByPk". A própria IDE vai mostrar os nomes das propriedades/colunas
necessárias que precisam ser passadas como parâmetro... e isso poupa tempo
na programação.

Quando é necessário um SELECT "diferente" pode-se usar a classe TDAOQUery
que tem métodos como QueryByTemplate( ) ou QueryByFreeSQL( ), por exemplo.
Essa classe tem até métodos para fazer agregações (GROUP BY), mas sempre
acaba surgindo alguma necessidade que precisa ser feita à mão. Mas fazer SQL
à mão é uma exceção, não a regra.


> Nosso maior problema é educar o programador... por exemplo, se ele quer
> > mostrar uma lista de pedidos com os nomes dos clientes, ele *NÃO* deve
> > fazer
> > uma query na tabela pedidos e depois varrer, dentro do FOR, mandando
> > exibir
>
> > conteúdo de  lista_pedido[i].Cliente.Nome (pois isso irá gerar um SELECT
> > pra cada pedido), mas SIM fazer uma query em uma view criada
> > especificamente
> > para este fim.
>
>
> Peraí, eu entendi direito? Fazer uma view por query específica do
> sistema?!
> Quantas
> views _por tabela_ você acha aceitável e/ou produtivo?
>
>
> Só curiosidade,


Mais uma vez, a questão aqui é o volume. Mais de 95% das tabelas não têm
view alguma; um punhado de tabelas, das mais utilizadas, ficaram com 5 ou 6
views cada uma, em média. Isso permite que os JOIN's mais complexos sejam
feitos à mão, nas VIEW's, otimizando o desempenho. A imensa maioria do
código que chega aos servidores é gerado pelo Framework.

A questão é que nenhum Framework tem inteligência suficiente para fazer
JOIN's complexos que apresentem um bom desempenho. Essa tarefa pode ficar
para o DBA ou para o programador, por exemplo. O resto dos comandos SQL, que
no fim das contas respondem por 99% dos comandos executados durante o
período de um dia, são simples e podem ser perfeitamente gerados pelo
Framework. Não é preciso muita inteligência para varrer um objeto e montar
um INSERT com as colunas necessárias -- por exemplo, verificando as colunas
que são NOT NULL, as propriedades que não estão com NULL e as colunas que
têm valor DEFAULT na tabela. O Framework consegue inclusive detectar alguns
problemas (como a falta de valor em uma propriedade cuja coluna é NOT NULL)
antes mesmo de mandar o comando para o banco de dados.

Mozart Hasse
>
>
>
> ___
> 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

[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=1591704&OrigenVisita=24&mailpos=3&alertaid=1212189&envioid=85762566&utm_source=inf&utm_medium=mail&utm_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

[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

[Alexsander Rosa]

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.

2008/4/20, Leandro DUTRA <[EMAIL PROTECTED]>:
>
> 2008/4/20, Alexsander Rosa <[EMAIL PROTECTED]>:
> >
> > 2008/4/20, Leandro DUTRA <[EMAIL PROTECTED]>:
> > > 2008/4/20, Alexsander Rosa <[EMAIL PROTECTED]>:
> > >
>
> > > > 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?
>
>
> Sim.  Respeito.
>
>
> --
>
> 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

[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

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

[Alexsander Rosa]

Comentários abaixo.

Em 21/04/08, Fábio Telles Rodriguez <[EMAIL PROTECTED]> escreveu:
>
> Em 21/04/08, Alexsander Rosa<[EMAIL PROTECTED]> escreveu:
>
> > 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.
> >
>
>
> Entendo a sua posição... mas veja, eu trabalho como PJ puro hoje. Isto
> significa que eu não tenho direito a férias, 13º e FGTS. Se um dia eu
> ficar doente, além de ter que arcar com o tratamento por conta
> própria, fico sem salário e se for algo sério, fico sem emprego
> também. Se resolverem me demitir, saio com uma mão na frente e outra
> atrás. Se eu perder um parente próximo, não tenho o direito sequer de
> ir no enterro. Eu tenho família, filhos, esposa, gato, cachorro,
> sogra, o pacote completo. Você vai me dizer que isso é uma escolha
> minha? Que eu não tenho o direito de querer constituir família e ter
> um mínimo de segurança para ela?


Com CNPJ você ganha aproximadamente duas vezes o que ganharia com CLT. Isso
quer dizer que se você ganha R$ 10 mil com CNPJ, deve viver como se ganhasse
R$ 5 mil e colocar os outros R$ 5 mil em investimentos. Você pode, por
exemplo, ter um plano de previdência que paga quase o dobro do que paga o
INSS. Pode colocar os 16,5% equivalentes ao FGTS numa conta com rendimentos
superiores ao FGTS, e assim por diante. Assim, se você for demitido (ou
mesmo pedir demissão, pois o dinheiro vai render igual) pode ganhar até
mais.

Com CLT você apenas está delegando essa poupança para o governo, e todos
sabemos que o governo é incompetente para gerenciar o dinheiro dos outros.
Por exemplo: veja quanto uma pessoa contribui de INSS (15% do salário, os
7,5% descontados mais os 7,5% do empregador) e quanto ela vai ganhar quando
se aposentar; depois compare com um plano VGBL ou PGBL privado com a mesma
contribuição. Nos planos privados o aposentado ganha entre 50% e 100% a mais
que com o INSS.

O sistema do INSS, de repartição, é feito de modo que os ativos pagam as
aposentadorias dos inativos. Isso quer dizer que o dinheiro que você está
contribuindo não é para você, mas para pagar as pensões dos seus pais e
avós. Essa fórmula é matematicamente insuficiente, por isso de tempos em
tempos é preciso fazer "ajustes" (aumentar o tempo de contribuição, diminuir
os valores das aposentadorias, etc). A nossa aposentadoria será paga por
nossos filhos e netos. Se a população "envelhecer" vai faltar dinheiro -- e
isso já está acontecendo, os idosos estão vivendo mais e esse é um dos
motivos do eterno "rombo da previdência". Esse rombo é inevitável com esse
sistema, ainda mais com o acréscimo de beneficiários extras como os
"perseguidos pela ditadura" por exemplo.

É claro que existem distorções na CLT. A CLT não foi feita para
> proteger o empregador, foi feita para proteger o empregado. São
> conquistas que custaram a vida de muitos trabalhadores por mais de um
> século de luta no país. Hoje os sindicatos são coisas vergonhosas que
> vivem a custa do imposto sindical. Mas a história não foi sempre
> assim. As jornadas de 16 horas nas fábricas em condições desumanas
> existem até hoje. O trabalho escravo no Brasil existe até hoje e
> muitas vezes bem debaixo dos nossos olhos.


Excesso de vantagens gera desemprego, especialmente na ponta de baixo: o
salário mínimo custa quase R$ 900 mensais ao empregador. Se uma pessoa não
tem qualificação para fazer um trabalho que produza pelo menos uns R$ 1000
mensais, vai ficar desempregada. Os mais afetados por esse problema são os
jovens sem experiência e os menos qualificados.

Porque no Brasil até pra contratar um Ajudante de Estoque (leia-se
carregador de caixas) é preciso fazer um monte de entrevistas e background
checks, enquanto nos países ricos o patrão coloca um cartaz "HELP WANTED" na
vitrine, o candidato pega o cartaz e sai trabalhando? Se aprovar, fica, se
não aprovar, recebe o dia trabalhado e tchau. Aqui as empresas ficam cheias
de receios por causa do excesso de leis trabalhistas. O cara pode trabalhar
um dia e depois entrar na Justiça pedindo mundos e fundos e a empresa vai
ter que pagar, tendo culpa ou não.

Não tirem por base um grupo de profissionais de "elite" como o nosso aqui
nessa lista, com alto nível de escolaridade e altamente qualificado. No
mundo real está cheio de funcionários querendo tirar vantagem e um monte de
advogados prontos para distorcer o sistema. Conver

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

[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

[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

[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

[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

[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

[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

[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

[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

Re: [pgbr-geral] (sem assunto)

[Alexsander Rosa]

Uma possibilidade seria codificar 731AAA como 731656565 onde 65 é o ASCII do
"A".
Outra possibilidade seria criar uma "stored procedure" para incrementar esta
coluna.
Também poderia experimentar um "overload" na operação de adição (dá pra
fazer isso?).

2008/9/5 Murilo Habermann Torquato <[EMAIL PROTECTED]>

> Bom dia pessoal,
>
> Estou com um probleminha e não estou encontrando, gostaria de saber se
> alguem conheçe uma solução, ou algo que possa me levar a ela para o seguinte
> caso:
>
> Tenho um campo chamado seq cujo valor é "731AAA". Preciso somar "1" neste
> campo, e o resultado deve ser "731AAB" e assim por diante.
>
> Existe algum tipo, ou função no próprio postgres que consiga fazer isso?
>
> []' s
>
> --
> Murilo Habermann Torquato
> http://fbeltram.muriloht.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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Resultado do PG Con 2007

[Alexsander Rosa]

Achei excelente. Conhecer a comunidade, que eu confesso que nem sabia que
era tão ativa, foi gratificante. Eu participei um pouco da lista antiga do
Yahoo e estava em "web-only" há anos, nem me lembrava que existia. Na época
eu achava a lista meio "parada", eis um post meu de 2003:

http://br.groups.yahoo.com/group/postgresql-br/message/20490

Usava um e-mail do Yahoo que tenho lido pouco recentemente... na época da
"unificação", lembro de ter colocado imediatamente em "digest mode" --
afinal, era uma lista que eu achava muito "parada" que aparentemente tinha
apenas trocado de servidor. Deve ter havido alguma mensagem informando sobre
a unificação mas deve ter passado despercebida no meio do digest.

Parabenizo a organização do evento pelo excelente trabalho. Ah, e a título
de informação: fiquei sabendo do PG Con pelo BR-Linux (que leio via RSS) e
depois fui quase "intimado" a comparecer pelo David Fetter, na #postgresql
do irc.freenode.net, que freqüento há muitos anos.

PS: Sou o cara do cavanhaque grisalho que estava com a camiseta pólo do PG
Con 2007 ;-)

-- 
Atenciosamente,

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

[pgbr-geral] Canal #postgresql-br no IRC do Freenode

[Alexsander Rosa]

Vi um slide, lá no PG Con, divulgando as listas e o canal de IRC.
O slide do IRC passou muito rápido, nem deu pra ver direito...
Se não me engano, havia um erro de digitação: estava irc.freenodeS.net !
O correto é irc.freenode.net (sem S) e os canais são:

#postgresql (em inglês)
#postgresql-br (em português)

Eu uso o nick "rednaxel" e costumo freqüentar os dois canais.

-- 
Atenciosamente,

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

Re: [pgbr-geral] FISL 9.0 - Inscrições quase enc erradas

[Alexsander Rosa]

Fui convencido por nosso amigo David Fetter a enviar uma proposta falando
sobre o sistema de replicação de emergência que desenvolvi, sobre o qual
conversamos. Ele funciona via linha discada e via GPRS (celular), para
aqueles momentos não tão raros onde a rede cai e os dados precisam fluir
(mesmo com algum delay).

O mecanismo é o seguinte: o programa tem duas fases, envio e recebimento.
Primeiro ele pega um conjunto de comandos a ser replicados de A para B
(chamado de "pacote"), compacta e gera um md5. Os dois arquivos (.gz e .md5)
são enviados via FTP para um servidor web, numa conta com acesso apenas a
uma pasta. Os pacotes são numerados seqüencialmente. Na segunda fase, ele
busca via HTTP num servidor web (pode ser o mesmo) o próximo pacote de B
para A; se ele conseguir baixar e o md5 estiver OK, ele aplica os comandos
gerados por B no servidor A.

As vantagens desse sistema são que ele não requer VPN (nem sempre
disponível) nem qualquer configuração especial de rotas, pode ser ativado em
poucos minutos e maximiza o uso da banda estreita. Em geral se configura no
cron um intervalo de 5 minutos entre os pacotes.

Em 11/12/07, Fernando Ike <[EMAIL PROTECTED]> escreveu:
>
> Salve galera,
>
>Desculpem o cross-posting, vocês entenderam o porque. Ainda estou
> escrevendo sobre o que foi evento na minha opinião mas acho que está
> ficando grande. Como nosso entusiasmo permanece, essa semana é a última
> semana para
> inscrever palestras para o FISL 9.0[1], como também o evento
> comunitário[2] no FISL.
>
>O evento comunitário é um momento especial do FISL que os Grupo de
> Usuários podem debater, discutir, fazer festa de caça aos bugs, etc.
> Enfim atividades do grupo de usuários durante o evento. Normalmente no
> Grupo de Usuários Debian Brasil nós fazemos uma plenária com as
> novidades do projeto, balanço de atividades e como organizar melhor o
> grupo de discussão. Isso é importante e no FISL 8.0 (2007) também
> fizemos isso e foi muito bom, ao menos na minha avaliação. :)
>
>Neste ano (2007) tivemos um estande patrocinado por empresas que
> ajudam o pg-br e creio que teremos para o FISL 9.0 mas essa parte
> precisamos começar a organizar desde já.
>
>O prazo final para enviar uma proposta de palestra é dia 15 de
> dezembro como também do evento comunitário. Convido todos que enviaram
> palestra para o pgcon-br também enviem proposta de palestra para o
> FISL e quem tem vontade de falar algo sobre PostgreSQL faça, encaminhe
> uma proposta para o FISL e avise na lista pgbr-dev que eu coloco no wiki
> do pgbr. Assim ninguém terá que aturar-me no palco falando besteiras de
> tuning em PostgreSQL no palco. =)
>
>
> Referências:
> 1 - http://www.softwarelivre.org/news/10292
> 2 - http://www.softwarelivre.org/news/10477
>
>
> meus dois centavos,
> --
> Fernando Ike
> http://www.midstorm.org/~fike/weblog
> ___
> 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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Transação

[Alexsander Rosa]

http://www.postgresql.org/docs/8.2/static/plpgsql-structure.html
"Functions and trigger procedures are always executed within a transaction
established by an outer query — they cannot start or commit that transaction,
since there would be no context for them to execute in."

2007/12/11, Julio Cesar Merenda Catardo <[EMAIL PROTECTED]>:
>
>  Alguém sabe como fazer uma trasação dentro de uma função 
>
> estou tentando :
>
>
> BEGIN;
> BLA.BLA.BLA.BLA
> COMMIT;
>
> ___
> 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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] material palestras PG Con 2007

[Alexsander Rosa]

Evandro, pelo menos ele não usou o e-mail corporativo... :-)
Acho que ninguém lá vai saber quem é o Mr JL do Yahoo. :-))

2007/12/12, Evandro Ricardo Silvestre <[EMAIL PROTECTED]>:
>
> > (...)
> Veja isso:
>
> http://cio.uol.com.br/carreira/2007/12/11/idgnoticia.2007-12-11.7261329136/
>
> Att
>
> Evandro
>
>
-- 
Atenciosamente,

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

Re: [pgbr-geral] 25gb de imagem, isso presta?

[Alexsander Rosa]

Conforme comentei no PG Con, eu armazeno apenas o PATH. Na verdade são
imagens de produtos e nem sequer há um campo pra PATH em cada imagem, mas
sim por servidor; o nome das imagens sempre é o código adicionado à extensão
.jpg e o sistema monta o PATH sozinho. Por exemplo, no servidor PG em
10.10.0.2 o campo PATH é "imagens", o servidor de imagens é "10.10.0.4". O
PATH da imagem do produto 1234 fica "http://10.10.0.4/imagens/1234.jpg"; com
tudo em minúsculas.

Isso permite que o servidor das imagens seja independente do servidor do BD.
Além disso, outras pessoas (pessoal do marketing, compras, etc) podem
colocar as imagens no diretório correspondente (do Apache) de forma
transparente para o DBA. Na hora de exibir uma imagem, se o arquivo não for
encontrado no servidor web é exibida a mensagem "Sem imagem".

Em 14/12/07, Roberto Baselio Lopes <[EMAIL PROTECTED]> escreveu:
>
> Em 14/12/07, Leandro Damascena <[EMAIL PROTECTED]>
> escreveu:
> >
> > Paulo Saimon Ramos escreveu:
> > > sim, vai dar certo se sua itenção é destruir tua rede, micro e banco
> > > de dados.
> > > Que pergunta mais estúpida.
> > >
> > ACHO que para o bem geral podemos discordar de pensamentos/idéias do
> > próximo de uma forma mais produtiva (... educada ...)  e manter o foco
> > na solução/dúvida/idéia... :-D
> >
> > Leandro Damascena.
> > ___
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
>
> Leandro, como ja dito anteriormente, eu recomendo salvar o caminho do
> arquivo no banco, geralmente salvar arquivos costuma se desencorajado pela
> maioria dos DBA's, mas é claro que sempre há exceções. Num ambiente Cliente
> windows e servidor Linux por exemplo, não tenho idéia se isso é possivel.
>
> --
> Roberto Baselio Lopes
> e-mail / Google Talk: [EMAIL PROTECTED]
> msn: [EMAIL PROTECTED]
> Curriculo: http://www2.curriculum.com.br/ucn/rbaselio
> ___
> 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] 25gb de imagem, isso presta?

[Alexsander Rosa]

O legal da modelagem que usei é que no BD tudo são strings e o usuário e/ou
o sysadmin podem colocar o conteúdo que quiserem nos campos, seja na forma
de IP, seja na forma de um dns alias... para o DBA e para o programador isso
tudo é transparente. :-)

Em 14/12/07, Leandro DUTRA <[EMAIL PROTECTED]> escreveu:
>
> 2007/12/14, Alexsander Rosa <[EMAIL PROTECTED]>:
> > Por exemplo, no servidor PG em
> > 10.10.0.2 o campo PATH é "imagens", o servidor de imagens é "10.10.0.4".
> O
> > PATH da imagem do produto 1234 fica "
> > http://10.10.0.4/imagens/1234.jpg"; com tudo em minúsculas.
>
> Nota aos incautos: o uso de IP pode causar danos à saúde.
>
> A recomendação é nunca usar endereços IP, mas um apelido DNS
> designando um serviço, apontando para o nome do hospedeiro.
>
> --
> +55 (11) 5685 2219   xmpp:[EMAIL PROTECTED]
> +55 (11) 9406 7191  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300  ICQ/AIM: aim:GoIM?screenname=61287803
> 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] 25gb de imagem, isso presta?

[Alexsander Rosa]

Eu entendi perfeitamente a colocação do Leandro... o que eu falei é que o
meu campo é texto e o usuário e/ou sysadmin que decidiram colocar o número
IP ao invés de um DNS alias. Não fui EU quem colocou IP nem seria EU que
poderia evitar isso, a menos que fizesse algum tipo de parsing na string
informada. Posso, claro, SUGERIR que eles corrijam isso criando um DNS alias
e mostrando em que parte da GUI isso é configurado na aplicação.

Em 15/12/07, Leandro Damascena <[EMAIL PROTECTED]> escreveu:
>
> Alexsander Rosa escreveu:
> > O legal da modelagem que usei é que no BD tudo são strings e o usuário
> > e/ou o sysadmin podem colocar o conteúdo que quiserem nos campos, seja
> > na forma de IP, seja na forma de um dns alias... para o DBA e para o
> > programador isso tudo é transparente. :-)
> >
> Mas o que o Leandro Dutra pediu cuidado não foi com a modelagem e sim
> pelo fato de você colocar IP no PATH e não nome (DNS), amanhã a máquina
> que "mora" esses arquivos precisar trocar o IP e lá vai você correr
> atrás para dar UPDATE nesses registros para garantir o funcionamento da
> aplicação... Problema esse que você poderia ter evitado criando uma
> entrada no DNS ou uma tabelinha de alias para IP->NOME...
>
> E te falar, já vi isso acontecer e foi um desespero para atualizar todos
> os registros e não comprometer a aplicação...
>
> Leandro Damascena.
> ___
> 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] Planos de Hospedagem com PostgreSQL

[Alexsander Rosa]

Eu uso a Tehospedo há anos, eles têm PostgreSQL 8.1.x:
http://www.tehospedo.com.br

PS: Se contratar, diz que eu indiquei ... :-)

Em 15/12/07, Sergio Medeiros Santi <[EMAIL PROTECTED]> escreveu:
>
>  Pessoal:
>
> Fiquei preocupado! A alguns dias estou procurando por hopedagens que
> incluam o Postgres. Olhei a Locaweb, a Dialhost e a IGempresas. Sabem qual é
> o problema?  A Locaweb ainda não consegui descobrir e as outras duas,
> pasmem, oferecem a moderníssima 7.4. Bem não é de admirar que muitas só
> ofereçam PHP 4.
>
> Alguém pode me sugerir algum outro? Devo preferir os brasileiros ou isto
> não é relevante?
>
> Abraços,
>
>  Sergio Medeiros Santi
>
>
>
> ___
> 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] check foreign key

[Alexsander Rosa]

Pode-se postergar a checagem de chaves:
http://www.postgresql.org/docs/current/static/sql-set-constraints.html

BEGIN;

SET CONSTRAINTS ALL DEFERRED;

INSERT INTO  ...
<...>

COMMIT;


Mas isso não *desliga* a checagem, apenas posterga (deixa para o final).
Quando o COMMIT for executado as constraints serão todas checadas. Há casos
raros onde dois registros em duas tabelas diferentes se referenciam
mutuamente com chaves estrangeiras não-nulas -- não me perguntem, mas já vi
isso :-). Nesse caso, um INSERT em uma requer um INSERT na outra mas ambos
falham por causa das chaves estrangeiras. Com esse comando pode-se fazer os
dois INSERTS numa transação. Para permitir futuramente que se use o comando
acima, as constraints em questão precisam ser declaradas como DEFERRABLE
(ver documentação).

Não sei se isso resolve o problema do Junior Prado...

Em 18/12/07, Euler Taveira de Oliveira <[EMAIL PROTECTED]> escreveu:
>
> junior Prado wrote:
>
> > Como desligar e ligar a checagem de chaves estrangeiras?
> >
> > check foreign key = 0; //está certo?
> >
> Não existe tal comando no PostgreSQL. Para desabilitar verificação de
> chaves estrangeira somente removendo-as e depois recriando-as.
> Certifique-se que não manipulará os dados entre estas duas etapas pois
> você poderá não conseguir recriar as chaves estrangeiras.
>
> ALTER TABLE foo DROP CONSTRAINT bar_col_fkey;
>
>
> --
>   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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgAdminIII

[Alexsander Rosa]

Até o ICron pode servir...
http://surguy.net/articles/icron.xml

Em 19/12/07, Marcelo <[EMAIL PROTECTED]> escreveu:
>
> Prezados
>
> - Alguma possibilidade de configurar o pgAdmin para rodar um  Backup
> automaticamente.?
>  num Windows Server 2003*..?*
>
>
> Grato.
> --
> Marcelo
> ___
> 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] Mapeamento Relacional-Objeto

[Alexsander Rosa]

Disclaimer: Eu sei que muita gente odeia mapeamentos e geradores de código.
:-)

Normalmente se fala em Mapeamento Objeto-Relacional, que a grosso modo
consiste em pegar um modelo O-O (modelado talvez em UML) e gerar um modelo
E-R. A modelagem é feita pensando em objetos e quem modela a camada de
persistência que se vire depois pra encaixar tudo numa DDL.

A idéia é fazer o caminho inverso: fazer o modelo de dados PRIMEIRO e depois
gerar um conjunto de classes. Cada tabela vira uma classe, cada tupla vira
uma instância, cada coluna vira uma propriedade. O objetivo é facilitar a
vida do programador para algumas tarefas simples e repetitivas: carregar um
objeto por sua(s) PK e depois atualizar ou deletar este objeto, por exemplo.
Os SELECT mais complexos continuam sendo feitos em SQL, as VIEWs continuam
sendo usadas normalmente. Não seria uma O-O de verdade, mas apenas um
wrapper para simplificar as tarefas.

O grande problema das camadas de persistência é que nunca se sabe a
qualidade do SQL gerado e é relativamente fácil para o programador usar
alguma classe de forma a gerar SQL ruim (ou mesmo péssimo). No entanto, a
maioria dos SQL usados pelas telas de cadastro em uma aplicação comercial
são simples. Nesses casos, um "SELECT  FROM cliente WHERE codigo =
1234" pode ser gerado automaticamente de maneira eficiente. Da mesma forma,
um "UPDATE cliente SET nome = 'Zeca' WHERE codigo = 1234" ou um "DELETE FROM
cliente WHERE codigo = 1234" podem ser gerados automaticamente sem
problemas.

Escrevi em 2003 uma OPF e um Gerador de Código que faz exatamente isso para
Delphi e FPC. Até agora, as vantagens têm superado as desvantagens com
folga... :-) O programador não perde tempo com os SQL triviais (que acabam
sendo em grande volume), podendo dedicar mais atenção aos códigos SQL e
PL/pgSQL realmente importantes, mais diretamente relacionados com as regras
do negócio.

-- 
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] Mapeamento Relacional-Objeto

[Alexsander Rosa]

O meu caso é o mesmo do Evandro, com algumas diferenças. A empresa de
software é minha, o software pertence à nossa empresa, mas temos um contrato
com o cliente "piloto" que restringe um pouco a liberação do código. Eles
exigiram uma cláusula que nos proíbe de fornecer o software para
concorrentes deles, e isso impede o uso de uma licença open source (pois um
concorrente poderia baixar o código). No entanto nos próximos meses temos
uma renovação contratual e vou separar restrição apenas para a aplicação,
liberando o Framework de persistência.

Em 19/12/07, Leandro DUTRA <[EMAIL PROTECTED]> escreveu:
>
> 2007/12/19, Alexsander Rosa <[EMAIL PROTECTED]>:
> > Escrevi em 2003 uma OPF e um Gerador de Código que faz exatamente isso
> para
> > Delphi e FPC. Até agora, as vantagens têm superado as desvantagens com
> > folga... :-) O programador não perde tempo com os SQL triviais (que
> acabam
> > sendo em grande volume), podendo dedicar mais atenção aos códigos SQL e
> > PL/pgSQL realmente importantes, mais diretamente relacionados com as
> regras
> > do negócio.
>
> Que tal botar no pgFoundry, SourceForge, Savannah ou coisa assim?
>
> --
> +55 (11) 5685 2219   xmpp:[EMAIL PROTECTED]
> +55 (11) 9406 7191  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300  ICQ/AIM: aim:GoIM?screenname=61287803
> 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] ALTER TABLE

[Alexsander Rosa]

Está dizendo que a coluna "is_motor_id" não existe na tabela "t_veiculo".

2007/12/20, Geion Correia <[EMAIL PROTECTED]>:
>
> Caros,
>
> Eu preciso adicionar uma chave estrangeira (is_motor_id) a uma
> tabela (t_veiculo) só que estou tendo dificuldade:
>
> ALTER TABLE t_veiculo ADD CONSTRAINT fk_is_motor_id
> FOREIGN KEY (is_motor_id) REFERENCES t_veiculo(t_motor) MATCH FULL;
>
> ERROR: column "is_motor_id" referenced in foreign key constraint does not
> exist
>
>
> O que estou fazendo de errado?
>
>
> Obrigado.
>
>
>
>
> ___
> 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] Retornar erros em Portugues

[Alexsander Rosa]

Veja no final do postgresql.conf onde configurar isso.

Em 21/12/07, Saulo <[EMAIL PROTECTED]> escreveu:
>
>  Bom dia pessoal. O PG tem suporte para retornar erros  para o usuário de
> consultas, autenticação, etc em português?
>
> Se não, alguém poderia me dar uma dica de como vc´s fazem?
>
> Obrigado
>
> ___
> 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] [pgbr-dev] Estudo de caso para o PostgreSQL

[Alexsander Rosa]

Eu enviei uma proposta: "Apagando incêndio: Replicação sobre linha discada".
O título foi uma sugestão do David Fetter, mas ele disse pra usar algo como
"under fire" (que seria na verdade algo como "sob fogo cruzado"). No final
achei que ficaria melhor usar a expressão "apagando incêndio" pra ilustrar a
necessidade de resolver problemas urgentes num curto espaço de tempo.

Em 27/12/07, Diogo Biazus <[EMAIL PROTECTED]> escreveu:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Caros Senhores,
>
> Estou enviando o email para as duas listas, pois precisamos de um estudo
> de caso para o FISL. Parece que até agora nenhum estudo de caso
> envolvendo o PostgreSQL foi inscrito no FISL 9.0.
>
> Alguém pretende fazer esse tipo de palestra? Se alguém que apresentou um
> estudo de caso quiser reapresentar no FISL eu também acho interessante,
> pois lá teremos um publico maior e mais variado.
>
> O prazo para submissão de palestras é até dia 11/01, e o procedimento é
> bem simples, basta se inscrever como palestrante no site:
> https://fisl.softwarelivre.org/9.0/papers/speaker/
> E colocar um resumo da palestra no sistema.
> Para mais informações:
> http://fisl.softwarelivre.org/9.0/www/chamadadetrabalhos
>
> - --
> Diogo Biazus - [EMAIL PROTECTED]
> Softa Consultoria
> http://www.softa.com.br
> http://www.postgresql.org.br
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHc8oPVnGJU0uKEMoRAmMiAKDbNFgDkrmHUd/Y2TQZ5VtfKo9t8gCcD/Ys
> SEezof3woXjsYaAhAqculr4=
> =8KFz
> -END PGP SIGNATURE-
> ___
> pgbr-dev mailing list
> [EMAIL PROTECTED]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-dev
>



-- 
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] Estudo de caso para o PostgreSQL

[Alexsander Rosa]

Acabei de submeter OUTRA palestra: "PostgreSQL na Casa do Papel". Já
conversei com o Gerente de TI deles, ele inclusive vai submeter uma sobre o
uso de software livre na empresa. Eles começaram a usar Software Livre (SL)
ainda com o Star Office (precursor do Open Office), hoje são 100% SL em
servidores e 99% SL nos desktops e notebooks.

Em 27/12/07, Diogo Biazus <[EMAIL PROTECTED]> escreveu:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Joao wrote:
> > Caro Diogo
> > Você já tem as possíveis palestras em mãos?
> > Gostaria de saber os temas estava pensando em falar sobre o slony,
> apesar de
> > ser bem batido o tema
>
> Não tenho acesso a lista completa de palestras submetidas.
> Mas aplestras sobre Slony nunca são demais, eu acho. Caso o tema tenha
> muitas palestras repetidas pode deixar para o pessoal da seleção de
> palestras filtrar isso.
> Não deixem de enviar palestras por achar o tema batido, o máximo que
> vocês perderão é uns 15 minutos necessários para preencher a proposta no
> site.
>
> - --
> Diogo Biazus - [EMAIL PROTECTED]
> Softa Consultoria
> http://www.softa.com.br
> http://www.postgresql.org.br
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHc9nUVnGJU0uKEMoRAk9UAJ98OYwmsyfOpZyk2V7x8sy33BPp9wCgzZbq
> x4Jjj+Y3ygZtWo5NENPO1EY=
> =1bui
> -END PGP SIGNATURE-
> ___
> 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] Replicação Multi-Master Assíncr ona

[Alexsander Rosa]

Estava conversando no IRC [1] com o DiogoB sobre Replicação Multi-Master
Assíncrona, mais especificamente sobre o replicador que escrevi para uso com
linha discada em casos de queda da banda larga -- o mesmo sobre o qual
submeti uma palestra ao FISL 9. O código ainda não é aberto, por motivos
contratuais, mas espero mudar isso em um ou dois meses. Achei que seria
interessante colocar aqui um trecho do log de um dia em que a ADSL de uma
das filiais [2] caiu (e ficou desligada por alguns dias). Eis o log:

Wed Dec 12 09:00:01 2007 [21242]: /--- INICIANDO rnx_synchro2 v2.0.028 ...
Wed Dec 12 09:00:01 2007 [21242]: ENVIANDO   5: pacote 1579 com 258
comandos (37747841 a 37748098)
Wed Dec 12 09:00:02 2007 [21242]: ENVIANDO   5: Transferencia de
P001-005-001579.sql.gz para ftp.servidor.com deu OK
Wed Dec 12 09:00:02 2007 [21242]: Finalizado com 0 erros (59.00 KB/s).
Proximo comando: 37748099
Wed Dec 12 09:00:02 2007 [21242]: BUSCANDO   5: pacote P005-001-000763
de http://www.servidor.com/pacotes/
Wed Dec 12 09:00:02 2007 [21242]: BUSCANDO   5: iniciando processamento...
Wed Dec 12 09:00:02 2007 [21242]: BUSCANDO   5: carregando pacote
P005-001-000763.sql com 170 comandos (1687715 a 1687886)
Wed Dec 12 09:00:05 2007 [21242]: BUSCANDO   5: pacote P005-001-000763
processado com 0 erros.
Wed Dec 12 09:00:05 2007 [21242]: BUSCANDO   5: pacote P005-001-000763
gravado no BD local.
Wed Dec 12 09:00:05 2007 [21242]: \--- FINALIZANDO

Neste log, a loja código 1 é a matriz e a código 5 é a loja cuja ADSL caiu.
O sistema primeiro montou um pacote 001-005 (matriz -> filial) com 258
comandos (que foram gerados no intervalo entre dois pacotes sucessivos),
gerou um arquivo SQL e depois fez um gzip e um md5. A seguir ele verificou
se havia pacotes pendentes vindos da filial, e baixou o pacote 005-001 (com
170 comandos). Depois de baixar o pacote, o sistema compara o md5 e
"processa" o pacote, gravando os comandos no BD da matriz.

[1] irc://chat.freenode.net/postgresql-br
[2] Filial do cliente onde o replicador está instalado.

-- 
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] Order by

[Alexsander Rosa]

http://archives.postgresql.org/pgsql-bugs/2004-06/msg00144.php

Em 28/12/07, FDV Serginho <[EMAIL PROTECTED]> escreveu:
>
> Pessoal
>
> estou com um problema com o Order by no PostgreSQL. Ele está ignorando os
> espaços. Exemplo:
>
> Ele faz assim:
> Ana Aparecida dos Santos Ladeira
> Analine das Dores Silva de Castro
> Ana Maria Santelices da Silva
>
> Deveria fazer assim:
> Ana Aparecida dos Santos Ladeira
> Ana Maria Santelices da Silva
> Analine das Dores Silva de Castro
>
> É verdade que o "l" vem antes de M, porém tem um espaço em branco.
>
> Alguém pode me ajudar? Muito obrigado
>
> --
> ---
> Sérgio Antônio dos Santos
> Bacharel em Sistemas de Informação
> (31)8411-2320
> ___
> 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] Problemas com campo char

[Alexsander Rosa]

Eu já tive problemas com NOT NULL e DEFAULT juntos. O NOT NULL não aceita
NULL, mas o DEFAULT coloca um valor quando o campo é NULL -- no fim, eu
tenho usado o DEFAULT sem NOT NULL, até porque faz mais sentido.

Em 07/01/08, Pierre Sandora <[EMAIL PROTECTED]> escreveu:
>
> Ela passaria para 'S' através da aplicação, quando uma rotina de leitura
> de log tivesse analisado o registro. Eu pensei no inicio que fosse um
> problema de lógica na aplicação, só que este 'S' misterioso aparece em
> INSERTs feitos através do PgAdmin também. E sobre este DEFAULT, eu
> inicialmente omitia o campo para usar o valor default, depois que este
> problema começou daí passei a usar explicitamente o 'N', mas não funcionou.
>
> On Jan 7, 2008 4:34 PM, José Mello Júnior <[EMAIL PROTECTED]>
> wrote:
>
> > Experimenta colocar o INSERT assim:
> >
> >INSERT INTO agd.clcaulg (nr_cau,nr_prospecto,dt_inicio
> > ,dt_final,id_ativo,id_retificado,id_cancelado,nr_cltxtcau,preco,id_sacado,nr_usado)
> > VALUES ( OLD.nr_cau,OLD.nr_prospecto,OLD.dt_inicio,
> > OLD.dt_final,OLD.id_ativo,OLD.id_retificado,
> > OLD.id_cancelado,OLD.nr_cltxtcau,OLD.preco,OLD.id_sacado,DEFAULT);
> >
> > Muito embora da forma como estava não deveria aparecer outra informação
> > que não aquela que comandou a gravação. QUando esta informação passaria para
> > a situação 'S' ?
> >
> > --
> > José de Mello Júnior
> > 41.9957-2007
> > ___
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
> >
>
>
> --
> Pierre Sandora
> Cel.: (11) 8596-4670
> MSN: [EMAIL PROTECTED]
> E-mail: [EMAIL PROTECTED]
> Site: http://www.pierresandora.eti.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] [OT] Função de DBA

[Alexsander Rosa]

É muito antiga, mesmo. Ainda no final dos anos 80 eu briguei com um monte de
gente por causa dela, até arrumei confusão da SBC porque disse que a
profissão só seria regulamentada quando os dirigentes da época (formados em
diversas áreas, nenhum da Computação) se aposentassem ou morressem.

Faltava massa crítica na época, éramos um punhado de alunos mais um punhado
de graduados. Existe toda uma filosofia da SBC por trás, um exemplo é o
texto da "justificativa" da defesa do PL 1561 (que inviabiliza a
regulamentação):

http://homepages.dcc.ufmg.br/~bigonha/Sbc/pl1561-justifica.html

Escrevi em 2005 um texto criticando esse PL:
http://alexrosa.blogspot.com/2005/08/crtica-ao-pl-156103.html

Em 25/01/08, Benedito A. Cruz <[EMAIL PROTECTED]> escreveu:
>
>
>
>
>
> Essa regulamentação da profissão de informata é uma briga antiga.
> Não aconteceu porque a SBC nunca se interessou pela regulamentação e,
> quando se interessou, foi contra.
> Houve propostas de regulamentação anos atrás e foram bombardeadas pela
> SBC.
> Como a SBC é formada principalmente por acadêmicos, ele não têm esse
> tipo de problema que nós enfrentamos com o CREA e o CFA e, portanto, não
> estão nem aí.
>
>
> Bene
>
>
> [EMAIL PROTECTED] wrote:
> > Em tempo: embora tenha graduação e mestrado em informática, já fui
> > notificado pelo CREA que não posso fazer qualquer serviço de
> configuração
> > de redes sem a contratação de um engenheiro em eletrônica.
> >
> > Tenho a notificação escaneada e leio ela novamente cada vez que surge
> esse
> > assunto de regularização da profissão.
> >
> > Desculpem o OFF-TOPIC.
> >
> > []s
> > Claudimir Zavalik
> >
> >
> >> Então que o CRA brigue com o CREA que também anda se achando muito para
> >> cima
> >> da área de TI, graças a cursos vagabundos chamados "Engenharia da
> >> Computação" que pipocaram de uma hora para outra pelo país.
> >>
> >> 2008/1/24, Roberto Mello <[EMAIL PROTECTED]>:
> >>
> >>> 2008/1/24 Jean <[EMAIL PROTECTED]>:
> >>>
>  Ela ta cuidando desses negocios de RH, mais blz entaum nao tem nada
> 
> >>> haver né
> >>>
>  !!!
>  to me segurando pra nao dar uma risadinha 
>  valew obrigado 
> 
> >>> Cuidado, ela pode estar certa. Um tempo atras eu lembro que o CRA
> >>> estava tentando fazer com que toda pessoa que trabalha com informatica
> >>> caisse sobre a alcada do CRA. Isso causaria que uma empresa de
> >>> informatica nao poderia se qualificar para usar o SIMPLES para
> >>> impostos.
> >>>
> >>> E' mais um exemplo da burocracia que impera no Brasil, onde o CRA nao
> >>> esta' buscando beneficio nenhum para seus supostos membros, e onde o
> >>> governo obriga as pessoas e empresas a pagarem por algo mesmo quando
> >>> eles nao tem beneficio nenhum. Deveriam deixar o mercado decidir, ao
> >>> inves de freiar a economia dessa maneira.
> >>>
> >>> -Roberto
> >>> ___
> >>> pgbr-geral mailing list
> >>> pgbr-geral@listas.postgresql.org.br
> >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >>>
> >>>
> >> ___
> >> pgbr-geral mailing list
> >> pgbr-geral@listas.postgresql.org.br
> >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >>
> >>
> >
> >
> > ___
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
>
>
> --
> --
>
> Benedito A. Cruz
> Centro de Referência em Informação Ambiental - CRIA
> email [EMAIL PROTECTED]
> fone 55 19 3288 0466
>
>
> ___
> 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] [OT] Função de DBA

[Alexsander Rosa]

Podemos ir mais longe: TODOS os Conselhos deveriam ser extintos. Eles não
passam de máfias que fazem Reserva de Mercado à força (como os mafiosos que
cobram por "proteção"), servem apenas para proteger os membros da "famiglia"
e não prestam nenhum serviço à Sociedade.

2008/1/25, Roberto Mello <[EMAIL PROTECTED]>:
>
> 2008/1/25 Marcos Fabrício Corso <[EMAIL PROTECTED]>:
> > eu sou totalmente a favor da regulamentação da profissão
> > é duro vc ter que falar pra um cliente que teu sistema ou site é melhor
> do
> > que o de um pia de 12 anos
>
> Aqui nos EUA nao existe regulamentacao da profissao de informatica, e
> pelo que eu vejo a industria de tecnologia de informacao vai muito
> bem, obrigado. Tem pia' de 12 anos que e' mais talentoso que gente de
> 40, apesar de serem raros. Sem querer me enquadrar na categoria de
> "mais talentoso", mas eu escrevi programas para informatizacao de
> clinicas medicas quando eu tinha 9 anos, em BASIC no TK-2000 com 128
> KiB de memoria e drive externo de 5 1/4". Se eu tivesse sido proibido
> de faze-lo, provavelmente nao teria continuado a estudar informatica.
>
> Eu contrato gente para empresa que trabalho, e nao e' incomum uma
> pessoa que nao tenha formacao academica ser a mais qualificada,
> dependendo da area, apesar de preferirmos pessoal com formacao
> academica.
>
> Se a minha empresa (sou acionista) fosse obrigada por uma lei qualquer
> a contratar pessoal que fosse "regulamentado" por um conselho
> burocrata qualquer, eu teria que despedir 75% dos meus programadores,
> e provavelmente teria que fechar as portas, ou o meu custo subiria
> muito.
>
> A industria de tecnologia do Brasil precisa de estimulo. Precisa
> crescer para criar mais empregos, mais empreendores, mais inovacao. Os
> profissionais precisam se qualificar para competir no mercado global.
> Regulamentacao nao vai ajudar em nenhuma dessas metas.
>
> -Roberto
> ___
> 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] [OT] Função de DBA

[Alexsander Rosa]

Os sindicatos não precisam ser extintos, mas precisam ser modificados. Não
deve haver monopólio territorial e a adesão deve ser 100% voluntária. Os
sindicatos precisam voltar a ser o que deveriam ser, associações livres de
empregados que negociam em grupo com os empregadores em busca de melhores
contratos. A legislação atual dá poder demais aos sindicatos.

Em 25/01/08, Pablo Sánchez <[EMAIL PROTECTED]> escreveu:
>
> Então, que se extingam também os sindicatos.
>
> Em 25/01/08, Alexsander Rosa <[EMAIL PROTECTED]> escreveu:
> >
> > Podemos ir mais longe: TODOS os Conselhos deveriam ser extintos. Eles
> > não passam de máfias que fazem Reserva de Mercado à força (como os mafiosos
> > que cobram por "proteção"), servem apenas para proteger os membros da
> > "famiglia" e não prestam nenhum serviço à Sociedade.
> >
> > 2008/1/25, Roberto Mello <[EMAIL PROTECTED]>:
> > >
> > > 2008/1/25 Marcos Fabrício Corso <[EMAIL PROTECTED]>:
> > > > eu sou totalmente a favor da regulamentação da profissão
> > > > é duro vc ter que falar pra um cliente que teu sistema ou site é
> > > melhor do
> > > > que o de um pia de 12 anos
> > >
> > > Aqui nos EUA nao existe regulamentacao da profissao de informatica, e
> > > pelo que eu vejo a industria de tecnologia de informacao vai muito
> > > bem, obrigado. Tem pia' de 12 anos que e' mais talentoso que gente de
> > > 40, apesar de serem raros. Sem querer me enquadrar na categoria de
> > > "mais talentoso", mas eu escrevi programas para informatizacao de
> > > clinicas medicas quando eu tinha 9 anos, em BASIC no TK-2000 com 128
> > > KiB de memoria e drive externo de 5 1/4". Se eu tivesse sido proibido
> > > de faze-lo, provavelmente nao teria continuado a estudar informatica.
> > >
> > > Eu contrato gente para empresa que trabalho, e nao e' incomum uma
> > > pessoa que nao tenha formacao academica ser a mais qualificada,
> > > dependendo da area, apesar de preferirmos pessoal com formacao
> > > academica.
> > >
> > > Se a minha empresa (sou acionista) fosse obrigada por uma lei qualquer
> > > a contratar pessoal que fosse "regulamentado" por um conselho
> > > burocrata qualquer, eu teria que despedir 75% dos meus programadores,
> > > e provavelmente teria que fechar as portas, ou o meu custo subiria
> > > muito.
> > >
> > > A industria de tecnologia do Brasil precisa de estimulo. Precisa
> > > crescer para criar mais empregos, mais empreendores, mais inovacao. Os
> > > profissionais precisam se qualificar para competir no mercado global.
> > > Regulamentacao nao vai ajudar em nenhuma dessas metas.
> > >
> > > -Roberto
> > > ___
> > > 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 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] como obter caminho completo dos bin ários do pg

[Alexsander Rosa]

PS: pode fazer também assim:
select name, setting, extra_desc from pg_settings ;

2008/1/31, Alexsander Rosa <[EMAIL PROTECTED]>:
>
> no psql:
> # SHOW all ;
>
> Vê se alguma coisa te ajuda.
>
> 2008/1/31, Fernando de Oliveira <[EMAIL PROTECTED]>:
> >
> >  Pessoal,
> >
> > Preciso saber o local onde estão os binários do postgresql (Windows).
> >
> > Meu objetivo é executar o pg_dump.
> >
> > Tem alguma forma de conseguir isso via função ou consultando as tabelas
> > de sistema?
> >
> > []s
> > Fernando
> >
> >
> > ___
> > 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




-- 
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] como obter caminho completo dos bin ários do pg

[Alexsander Rosa]

no psql:
# SHOW all ;

Vê se alguma coisa te ajuda.

2008/1/31, Fernando de Oliveira <[EMAIL PROTECTED]>:
>
>  Pessoal,
>
> Preciso saber o local onde estão os binários do postgresql (Windows).
>
> Meu objetivo é executar o pg_dump.
>
> Tem alguma forma de conseguir isso via função ou consultando as tabelas de
> sistema?
>
> []s
> Fernando
>
>
> ___
> 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 - Ferramenta de desenvolvimento

[Alexsander Rosa]

Volta e meia estou editando código C no vi.
Emacs sucks! Vi rulez!

2008/2/7, Antonio Nascimento <[EMAIL PROTECTED]>:
>
> Não sou fã da MS, contudo para programar em C++ até hoje não encontrei
> nada melhor que o Visual Studio.
>
> Antonio Nascimento
>
> 2008/2/7 Pedro B. Alves <[EMAIL PROTECTED]>:
>
> > Qual seria a melhor IDE para programação em C++?
> > ___
> > 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

Re: [pgbr-geral] OFF TOPIC - Ferramenta de desenvolvimento

[Alexsander Rosa]

Eu também sou do RS. Estou desenvolvendo para o coletor de dados MC-3090 da
Symbol (que usa Microsoft(R) Windows™ CE 5.0 Professional) usando C, ncurses e
libpq. O coletor é um complemento do nosso ERP, para uso em depósitos
(warehouse). Ele tem wireless e leitor laser de código de barras.

Em 07/02/08, Pedro B. Alves <[EMAIL PROTECTED]> escreveu:
>
>
>
> 2008/2/7, Pablo Sánchez <[EMAIL PROTECTED]>:
> >
> > Então acho que o que vc vai precisar mesmo é de C++,e não C#.
>
>
>
> C++ foi minha primeira opnião... mas como eu não sei programar em C++ e
> não estou conseguindo nenhum curso aqui no meu estado, então estou tentando
> outras alternativas... sou do RS..
>
>
>
> ___
> 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] conectar via libpq em c++ windows ( dev-cpp )

[Alexsander Rosa]

Eis meu "compila_win.bat":

=== início
@ECHO OFF
SET PGINC="C:\Arquivos de programas\PostgreSQL\8.2\include"
SET PGLIB="C:\Arquivos de programas\PostgreSQL\8.2\lib"

SET CINC="C:\Dev-Cpp\include"
SET CLIB="C:\Dev-Cpp\lib"

SET CURLINC="C:\RNGE\Synchro\libcurl-7.16.0\include"
SET CURLLIB="C:\RNGE\Synchro\libcurl-7.16.0\lib"

DEL rnx_synchro2.pid

@ECHO ON
gcc -Wall rnx_synchro2.c md5.c -I%CINC% -I%PGINC% -I%CURLINC% -L%CLIB%
-L%PGLIB% -L%CURLLIB% -lcurl -lpq -o rnx_synchro2.exe
=== fim

Em 11/02/08, Fernando de Oliveira <[EMAIL PROTECTED]> escreveu:
>
> Pessoal,
> Estou tentando conectar ao Pg via libpq no windows xp utilizando o
> Dev-cpp,
> porém estou obtendo os seguintes erros ( Log do compilador ):
>
>
> --
> Executando  make...
> mingw32-make.exe -f "C:\Dev-Cpp\Projetos\testes\Makefile.win" all
> g++.exe Objects/MingW/main.o -o
> "Output\MingW\Teste.exe" -L"C:/Dev-Cpp/Lib" -L"C:/Arquivos de
> programas/PostgreSQL/8.3/lib"
>
> Objects/MingW/main.o:main.cpp:(.text+0xd): undefined reference to
> `PQfinish'
> Objects/MingW/main.o:main.cpp:(.text+0x69): undefined reference to
> `PQconnectdb'
> Objects/MingW/main.o:main.cpp:(.text+0x77): undefined reference to
> `PQstatus'
> Objects/MingW/main.o:main.cpp:(.text+0x86): undefined reference to
> `PQerrorMessage'
> Objects/MingW/main.o:main.cpp:(.text+0xc0): undefined reference to
> `PQexec'
> Objects/MingW/main.o:main.cpp:(.text+0xce): undefined reference to
> `PQresultStatus'
> Objects/MingW/main.o:main.cpp:(.text+0xde): undefined reference to
> `PQerrorMessage'
> Objects/MingW/main.o:main.cpp:(.text+0x105): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x11b): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x12e): undefined reference to
> `PQexec'
>
> Objects/MingW/main.o:main.cpp:(.text+0x13c): undefined reference to
> `PQresultStatus'
> Objects/MingW/main.o:main.cpp:(.text+0x14c): undefined reference to
> `PQerrorMessage'
> Objects/MingW/main.o:main.cpp:(.text+0x173): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x189): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x19c): undefined reference to
> `PQexec'
> Objects/MingW/main.o:main.cpp:(.text+0x1aa): undefined reference to
> `PQresultStatus'
> Objects/MingW/main.o:main.cpp:(.text+0x1ba): undefined reference to
> `PQerrorMessage'
> Objects/MingW/main.o:main.cpp:(.text+0x1e1): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x1f7): undefined reference to
> `PQnfields'
> Objects/MingW/main.o:main.cpp:(.text+0x21b): undefined reference to
> `PQfname'
> Objects/MingW/main.o:main.cpp:(.text+0x250): undefined reference to
> `PQntuples'
> Objects/MingW/main.o:main.cpp:(.text+0x27d): undefined reference to
> `PQgetvalue'
> Objects/MingW/main.o:main.cpp:(.text+0x2b2): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x2c5): undefined reference to
> `PQexec'
> Objects/MingW/main.o:main.cpp:(.text+0x2d3): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x2e6): undefined reference to
> `PQexec'
>
> Objects/MingW/main.o:main.cpp:(.text+0x2f4): undefined reference to
> `PQclear'
> Objects/MingW/main.o:main.cpp:(.text+0x2ff): undefined reference to
> `PQfinish'
> collect2: ld returned 1 exit status
>
> mingw32-make.exe: *** [Output/MingW/Teste.exe] Error 1
>
> Execução terminada
>
> 
>
>
> Ja pesquisei no google, mas não consegui resolver o problema.
> Aparentemente
> é problema de linkagem, já tentei passar os parâmetros mas não deu certo..
>
> Alguém pode me ajudar?
>
> []s
> Fernando de Oliveira
>
> ___
> 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] conectar via libpq em c++ windows ( dev-cpp )

[Alexsander Rosa]

Confira no C:\Arquivos de programas\PostgreSQL\8.3\lib se existe o arquivo "
libpq.a".
Fiz um teste aqui: renomeei o meu "libpq.a" e deu o mesmo erro que você
teve.

2008/2/11, Fernando de Oliveira <[EMAIL PROTECTED]>:
>
>  Erro retornado retirando "-lcurl"
>
>
> 
> C:\Dev-Cpp\Projetos\testes>C:\Dev-Cpp\bin\gcc -Wall 
> main.cpp-I"C:\Dev-Cpp\inclu
> de" -I"C:\Arquivos de programas\PostgreSQL\8.3\include" -L"C:\Dev-Cpp\lib"
> -L"C:
> \Arquivos de programas\PostgreSQL\8.3\lib"  -lpq -o teste.exe
> C:\Dev-Cpp\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe:
> cannot f
> ind -lpq
> collect2: ld returned 1 exit status
>
> ----
>
> muito agradecido pela ajuda.
>
> []s
> Fernando de Oliveira
>
> - Original Message -
> *From:* Alexsander Rosa <[EMAIL PROTECTED]>
> *To:* Comunidade PostgreSQL Brasileira
> *Sent:* Monday, February 11, 2008 3:02 PM
> *Subject:* Re: [pgbr-geral] conectar via libpq em c++ windows ( dev-cpp )
>
> Você precisa tirar a LIBCURL (que eu estou usando e você não).
> Remova o "-lcurl" da linha do gcc.
>
> Em 11/02/08, Fernando de Oliveira <[EMAIL PROTECTED]> escreveu:
> >
> >  Eis meu compila.bat adaptado pelo bat do Alexsander:
> >
> >  inicio 
> > @ECHO OFF
> > SET PGINC="C:\Arquivos de programas\PostgreSQL\8.3\include"
> > SET PGLIB="C:\Arquivos de programas\PostgreSQL\8.3\lib"
> >
> > SET CINC="C:\Dev-Cpp\include"
> > SET CLIB="C:\Dev-Cpp\lib"
> > SET GCCDIR=C:\Dev-Cpp\bin\
> >
> >
> > @ECHO ON
> > %GCCDIR%gcc -Wall main.cpp -I%CINC% -I%PGINC% -L%CLIB% -L%PGLIB%  -lcurl
> > -lpq -o teste.exe
> > fim 
> >
> > Erro retornado:
> >
> >
> > --
> > C:\Dev-Cpp\Projetos\testes>C:\Dev-Cpp\bin\gcc -Wall 
> > main.cpp-I"C:\Dev-Cpp\inclu
> > de" -I"C:\Arquivos de programas\PostgreSQL\8.3\include"
> > -L"C:\Dev-Cpp\lib" -L"C:
> > \Arquivos de programas\PostgreSQL\8.3\lib"  -lcurl -lpq -o teste.exe
> >
> > C:\Dev-Cpp\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe:
> > cannot f
> > ind -lcurl
> > collect2: ld returned 1 exit status
> >
> > ---
> >
> > []s
> > Fernando de Oliveira
> >
> >  - Original Message -
> > *From:* Alexsander Rosa <[EMAIL PROTECTED]>
> > *To:* Comunidade PostgreSQL Brasileira
> > *Sent:* Monday, February 11, 2008 1:44 PM
> > *Subject:* Re: [pgbr-geral] conectar via libpq em c++ windows ( dev-cpp
> > )
> >
> > Eis meu "compila_win.bat":
> >
> > === início
> > @ECHO OFF
> > SET PGINC="C:\Arquivos de programas\PostgreSQL\8.2\include"
> > SET PGLIB="C:\Arquivos de programas\PostgreSQL\8.2\lib"
> >
> > SET CINC="C:\Dev-Cpp\include"
> > SET CLIB="C:\Dev-Cpp\lib"
> >
> > SET CURLINC="C:\RNGE\Synchro\libcurl-7.16.0\include"
> > SET CURLLIB="C:\RNGE\Synchro\libcurl-7.16.0\lib"
> >
> > DEL rnx_synchro2.pid
> >
> > @ECHO ON
> > gcc -Wall rnx_synchro2.c md5.c -I%CINC% -I%PGINC% -I%CURLINC% -L%CLIB%
> > -L%PGLIB% -L%CURLLIB% -lcurl -lpq -o rnx_synchro2.exe
> > === fim
> >
> > Em 11/02/08, Fernando de Oliveira <[EMAIL PROTECTED]> escreveu:
> > >
> > > Pessoal,
> > > Estou tentando conectar ao Pg via libpq no windows xp utilizando o
> > > Dev-cpp,
> > > porém estou obtendo os seguintes erros ( Log do compilador ):
> > >
> > >
> > > --
> > > Executando  make.
> > > mingw32-make.exe -f "C:\Dev-Cpp\Projetos\testes\Makefile.win" all
> > > g++.exe Obj

Re: [pgbr-geral] conectar via libpq em c++ windows ( dev-cpp )

[Alexsander Rosa]

Você precisa tirar a LIBCURL (que eu estou usando e você não).
Remova o "-lcurl" da linha do gcc.

Em 11/02/08, Fernando de Oliveira <[EMAIL PROTECTED]> escreveu:
>
>  Eis meu compila.bat adaptado pelo .bat do Alexsander:
>
>  inicio 
> @ECHO OFF
> SET PGINC="C:\Arquivos de programas\PostgreSQL\8.3\include"
> SET PGLIB="C:\Arquivos de programas\PostgreSQL\8.3\lib"
>
> SET CINC="C:\Dev-Cpp\include"
> SET CLIB="C:\Dev-Cpp\lib"
> SET GCCDIR=C:\Dev-Cpp\bin\
>
>
> @ECHO ON
> %GCCDIR%gcc -Wall main.cpp -I%CINC% -I%PGINC% -L%CLIB% -L%PGLIB%  -lcurl
> -lpq -o teste.exe
> fim 
>
> Erro retornado:
>
>
> --
> C:\Dev-Cpp\Projetos\testes>C:\Dev-Cpp\bin\gcc -Wall 
> main.cpp-I"C:\Dev-Cpp\inclu
> de" -I"C:\Arquivos de programas\PostgreSQL\8.3\include" -L"C:\Dev-Cpp\lib"
> -L"C:
> \Arquivos de programas\PostgreSQL\8.3\lib"  -lcurl -lpq -o teste.exe
>
> C:\Dev-Cpp\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe:
> cannot f
> ind -lcurl
> collect2: ld returned 1 exit status
>
> -------
>
> []s
> Fernando de Oliveira
>
> - Original Message -
> *From:* Alexsander Rosa <[EMAIL PROTECTED]>
> *To:* Comunidade PostgreSQL Brasileira
> *Sent:* Monday, February 11, 2008 1:44 PM
> *Subject:* Re: [pgbr-geral] conectar via libpq em c++ windows ( dev-cpp )
>
> Eis meu "compila_win.bat":
>
> === início
> @ECHO OFF
> SET PGINC="C:\Arquivos de programas\PostgreSQL\8.2\include"
> SET PGLIB="C:\Arquivos de programas\PostgreSQL\8.2\lib"
>
> SET CINC="C:\Dev-Cpp\include"
> SET CLIB="C:\Dev-Cpp\lib"
>
> SET CURLINC="C:\RNGE\Synchro\libcurl-7.16.0\include"
> SET CURLLIB="C:\RNGE\Synchro\libcurl-7.16.0\lib"
>
> DEL rnx_synchro2.pid
>
> @ECHO ON
> gcc -Wall rnx_synchro2.c md5.c -I%CINC% -I%PGINC% -I%CURLINC% -L%CLIB%
> -L%PGLIB% -L%CURLLIB% -lcurl -lpq -o rnx_synchro2.exe
> === fim
>
> Em 11/02/08, Fernando de Oliveira <[EMAIL PROTECTED]> escreveu:
> >
> > Pessoal,
> > Estou tentando conectar ao Pg via libpq no windows xp utilizando o
> > Dev-cpp,
> > porém estou obtendo os seguintes erros ( Log do compilador ):
> >
> >
> > --
> > Executando  make..
> > mingw32-make.exe -f "C:\Dev-Cpp\Projetos\testes\Makefile.win" all
> > g++.exe Objects/MingW/main.o -o
> > "Output\MingW\Teste.exe" -L"C:/Dev-Cpp/Lib" -L"C:/Arquivos de
> > programas/PostgreSQL/8.3/lib"
> >
> > Objects/MingW/main.o:main.cpp:(.text+0xd): undefined reference to
> > `PQfinish'
> > Objects/MingW/main.o:main.cpp:(.text+0x69): undefined reference to
> > `PQconnectdb'
> > Objects/MingW/main.o:main.cpp:(.text+0x77): undefined reference to
> > `PQstatus'
> > Objects/MingW/main.o:main.cpp:(.text+0x86): undefined reference to
> > `PQerrorMessage'
> > Objects/MingW/main.o:main.cpp:(.text+0xc0): undefined reference to
> > `PQexec'
> > Objects/MingW/main.o:main.cpp:(.text+0xce): undefined reference to
> > `PQresultStatus'
> > Objects/MingW/main.o:main.cpp:(.text+0xde): undefined reference to
> > `PQerrorMessage'
> > Objects/MingW/main.o:main.cpp:(.text+0x105): undefined reference to
> > `PQclear'
> > Objects/MingW/main.o:main.cpp:(.text+0x11b): undefined reference to
> > `PQclear'
> > Objects/MingW/main.o:main.cpp:(.text+0x12e): undefined reference to
> > `PQexec'
> >
> > Objects/MingW/main.o:main.cpp:(.text+0x13c): undefined reference to
> > `PQresultStatus'
> > Objects/MingW/main.o:main.cpp:(.text+0x14c): undefined reference to
> > `PQerrorMessage'
> > Objects/MingW/main.o:main.cpp:(.text+0x173): undefined reference to
> > `PQclear'
> > Objects/MingW/main.o:main.cpp:(.text+0x189): undefined reference to
> > `PQclear'
> > Objects/MingW/main.o:main.cpp:(.text+0x19c): undefined reference to
> > `PQexec'
> > Objects/MingW/main.o:main.cpp:(.text+0x1

Re: [pgbr-geral] Canal #postgresql-br

[Alexsander Rosa]

Estou dentro!

Em 14/02/08, Roberto Mello <[EMAIL PROTECTED]> escreveu:
>
> Pessoal,
>
> Eu tenho ficado no #postgresql-br por uns tempos agora, e quase nunca
> tem ninguem por la'. IRC e' uma excelente maneira de trocar ideias, e
> ter um intercambio de discussoes muito mais dinamico que a lista de
> discussao.
>
> Os pouco que aparecem por la' fazem uma pergunta, esperam 3 minutos, e
> quando nao receberam resposta ainda vao-se embora. Nao entendem que se
> esperarem mais um pouco a resposta pode aparecer.
>
> Gostaria de convidar mais membros da lista a entrarem e *ficarem* no
> canal #postgresql-br na freenode. Sugiro usar um cliente que possa
> ficar conectado o tempo inteiro, como o irssi dentro de uma sessao do
> screen, ou usar o bip para ficar sempre conectado e acompanhar todas
> as discussoes.
>
> -Roberto
> ___
> 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] Database ocupando muito espaço no H D

[Alexsander Rosa]

Pra ver o tamanho do BD
select pg_size_pretty(pg_database_size('nome-da-base'));

Pra ver o tamanho de uma tabela
select pg_size_pretty(pg_relation_size('nome-da-tabela'));


Em 14/02/08, Hikari <[EMAIL PROTECTED]> escreveu:
>
> Eu estou com uma situação estranha aqui, talvez alguém saiba como
> resolver.
>
> Eu rodo o Postgres 8.2.4 no Windows, ele tem 2 databases sendo 1 pra
> testes bem pequeno e outro q quando faço backup o arquivo fica
> com 200KB.
>
> Acontece q o diretório \data tava ocupando 20.7GB!! Ele já tinha mais de 1
> ano, quando eu reinstalei o Postgres eu só mandei ele
> usar esse diretório. Há uns meses, pesquisando sobre isso que eu fui
> descobrir o VACUUM, só q ele não ajudou muito. Então eu fiz
> backup, reinstalei o Postgres completo e restaurei o backup, daí o \data
> ficou com uns 60MB...
>
> E agora tá acontecendo de novo, ele tá com 2.24GB já... eu rodo o VACUUM e
> nada do espaço diminuir.
>
> Vcs sabem oq pode estar causando isso e se tem alguma outra alternativa
> além de desinstalar e reinstalar?
>
>
>
>
> ---
> Hikari
> http://hikarinet.info
>
> ___
> 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] conectar via libpq em c++ windows ( dev-cpp )

[Alexsander Rosa]

Experimenta copiar pro diretório do exe. Ele vai pedir, sim, várias outras
DLL que acompanham, como libeay32.dll, ssleay32.dll e krb5_32.dll. No total
são umas 5 ou 6, não lembro ao certo. Vai copiando à medida em que ele vai
pedindo pra testar.

2008/2/18, Fernando de Oliveira <[EMAIL PROTECTED]>:
>
>  Consegui compilar o programa,
> entretanto na hora de executar, ele fala que não foi possível encontrar "
> libpq.dll", sendo que a mesma encontra-se no diretório \lib e \bin.
> Experimentei copiar para a pasta do exe, mas passa a pedir outra...
> obrigado a todos pela ajuda.
>
> Fernando
>
> - Original Message -
> *From:* Thiago Tiedtke <[EMAIL PROTECTED]>
> *To:* Comunidade PostgreSQL Brasileira
> *Sent:* Monday, February 11, 2008 10:59 PM
> *Subject:* Re: [pgbr-geral] conectar via libpq em c++ windows ( dev-cpp )
>
> Eu fiz o teste aqui, e minha linha ficou assim:
>
> gcc -Wall main.cpp -I"C:\Arquivos de programas\PostgreSQL\8.3\include"
> -L"C:\Arquivos de programas\PostgreSQL\8.3\lib" -llibpq -o teste.exe
>
> Compilou normalmente.
>
> Estou em Windows XP, com MinGW, gcc version 3.4.4 (mingw special)
>
> Primeiro criei um projeto no CodeBlocks, depois fiz na linha de comando.
>
> A única coisa que percebi de diferente foi isso:
>
> -llibpq e nao -lpq, como está no seu .bat
>
> []s
>
> Thiago tiedtke dos Reis
>
> --
>
> ___
> 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

Re: [pgbr-geral] Dúvida

[Alexsander Rosa]

Um palpite: não seria contra-barra?
"SELECT * FROM \"USUARIO\" "

2008/2/18, Andrea Santos <[EMAIL PROTECTED]>:
>
> A minha tabela se chama USUARIO.
>
> O caminho do path está configurado corretamento, tanto que ele consegue
> fazer o select, porém só faz se eu coloco o nome da tabela entre ""
>
> String sqk = "SELECT * FROM /"USUARIO/" "
>
>
> O que então poderia estar errado ? Existe alguma restrição com o nome da
> tabela estar em maiusculo?
>
>
>
> ___
> 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] foto em java e postgres

[Alexsander Rosa]

Isso foi discutido no PGCon 2007:

Preciso armazenar arquivos no banco. O que fazer? - Diogo Biazus
http://www.postgresql.org.br/Palestras_do_PGCon_Brasil_2007

2008/2/21, Eduardo <[EMAIL PROTECTED]>:
>
> Aproveitando a thread,
>
> Quais seriam os argumentos para justificar o armazenamento do banco X
> gravar em uma pasta a parte.
>
>
>
> Eduardo
>
>
>
>
>
>
> Dickson Guedes wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Marcos Fabrício Corso escreveu:
> >
> >> (...) e preciso que no cadastro de produto fique com a foto do
> >> produto o que tenho que fazer no postgres para isso, para gravar ??
> >>  e em java, como fazer, para selecionar a foto ?? (...)
> >>
> >
> >
> > http://jdbc.postgresql.org/documentation/83/binary-data.html
> >
> > []s
> > Guedes
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.2 (GNU/Linux)
> > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
> >
> > iD8DBQFHvXqsfNj5A+QkLMoRAr0yAJ9eTH8gwCQRHpcElXcLnj5+rnxEcACeIFYy
> > xVIo3OeikPrwhzz3k1z4fD8=
> > =mJh2
> > -END PGP SIGNATURE-
> >
> > ___
> > 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

Re: [pgbr-geral] Driver Vitavoom (Delphi+DBX+Postgres)

[Alexsander Rosa]

Eu uso com D7.

2008/2/25, Marlon David de Souza <[EMAIL PROTECTED]>:
>
> Boa tarde a todos,
>
>   Alguém já está utilizando o driver da Vitavoom juntamente com o Delphi
> 2007 for Win32?
>
> Sem mais,
>
>
> Marlon David de Souza
> Desenvolvimento
> Sysmo Informática Ltda
> ___
> 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] Como gerar um Dump de todo o banco a exceção dos dados de algumas tabelas?

[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

[Alexsander Rosa]

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

[Alexsander Rosa]

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

[Alexsander Rosa]

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] Distancia entre dusa cidade

[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

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

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

[Alexsander Rosa]

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

> 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

[Alexsander Rosa]

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

[Alexsander Rosa]

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

> 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 
> escreveu:
>
>> 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,  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

[Alexsander Rosa]

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

[Alexsander Rosa]

Vamos por partes.

Em 8 de julho de 2010 20:51,  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] Descobrir quando um determinado regis tro teve alteração

[Alexsander Rosa]

Não tem nem backups?

Em 16 de julho de 2010 11:26, Thiago  escreveu:

> Pessoal, bom dia.
>
> Tenho uma tabela e não tenho de logs dessa tabela para saber a data da
> última alteração mas percebi que a mesma foi feita uma alteração em um
> determinado registro.
>
> Gostaria de saber se em algum lugar o servidor ou em alguma tabela de
> próprio postgre eu tenho como saber quando se foi e quando foi feita a
> alteração.
>
> Estou utilizando a seguinte versão:
> PostgreSQL 8.1.11 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
> 4.1.2 20070626 (Red Hat 4.1.2-14)
>
> ___
> 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] Delete *

[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  escreveu:

> Olá,
>
> Em 22 de julho de 2010 11:25, Candido Vieira da Silva Neto  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
>>  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  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

[Alexsander Rosa]

Tem certeza que a modelagem está correta?

Em 26 de julho de 2010 11:52, Heloisa Fernanda escreveu:

> 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

[Alexsander Rosa]

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

Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
escreveu:

>  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