from:"Alexsander Rosa"

Em 13 de outubro de 2011 18:43,  desenvolvedor@gmail.com escreveu:
 Alexandre, poderia citar os malefícios das chaves artificiais?


Supondo que você esteja se referindo a mim (Alexsander), o problema é
o uso indiscriminado de chaves artificiais. Por exemplo, uma tabela de
CEP não precisa ter uma coluna id_cep como PK, o próprio CEP é uma
PK melhor. Neste caso, para saber o CEP de um logradouro é preciso um
JOIN a mais. Outro exemplo: porque usar id_sexo numeric se podemos
usar simplesmente sexo char(1) com um CHECK para garantir que seja
M ou F? Muita gente usa ID em toda a base, de ponta a ponta, e
isso é ruim.

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

Re: [pgbr-geral] Função Update or Insert

Em 14 de outubro de 2011 14:25, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
 2011/10/14 Charles Viana charles.vi...@gmail.com:

 Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir
 até 2 vezes ou mais.

 Exemplo:
 Rua Pio XII   Centro    Mairiporã    SP    0760
 Rua XV de Novembro    Centro    Mairiporã    SP    0760

 Mas aí é uma tabela de endereços, não de CEPs.


Exato. No site dos Correios, se você pesquisar por 0760 vem
apenas a cidade de Mairiporã.


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

Re: [pgbr-geral] Modelagem (era: Função Update or Insert)

Em 14 de outubro de 2011 15:58, Shander Lyrio
shan...@nucleo45.com.br escreveu:
 Em 14-10-2011 15:08, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 2011/10/14 Marcal Hokamamhok...@hotmail.com:
 From: l...@dutras.org

 Mas aí é uma tabela de endereços, não de CEPs.

 Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a 
 relação entre CEP e logradouro, onde um único CEP pode ser referenciado por 
 mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 
 em algumas localidades (vide [1]).

 Ou seja, poderíamos dizer que é CEP n:m logradouros, certo?

        Lindo na teoria e péssimo na prática. Um cep que termine com a faixa de
 990 à 998 não está associada a um logradouro. Se quiser forçar a barra
 deste jeito você teria que ter relacionamentos n:m para caixas postais,
 bairros, logradouros, cidades, estados, além de grandes usuários e cep's
 promocionais que são usados ao gosto dos correios.

        Você acha que isto é usável?

A tabela de CEP tem a grande utilidade de padronizar dados. Não se
trata de armazenar um endereço como CEP mais alguma coisa, mas sim
usar a tabela de CEPs para PREENCHER o endereço corretamente. Sem
isso, uma rua com a palavra WASHINGTON acabaria sendo cadastrada com
diversas grafias. O mesmo vale para os bairros: aqui em Porto Alegre
tem um bairro chamado MONT SERRAT que, sem um cadastro de CEP (ou
equivalente), seria preenchido de diversas maneiras criativas pelos
usuários.

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

Re: [pgbr-geral] Modelagem (era: Função Update or Insert)

Em 14 de outubro de 2011 16:29, Shander Lyrio
shan...@nucleo45.com.br escreveu:
 Em 14-10-2011 16:05, Alexsander Rosa escreveu:
 Em 14 de outubro de 2011 15:58, Shander Lyrio
 A tabela de CEP tem a grande utilidade de padronizar dados. Não se
 trata de armazenar um endereço como CEP mais alguma coisa, mas sim
 usar a tabela de CEPs para PREENCHER o endereço corretamente. Sem
 isso, uma rua com a palavra WASHINGTON acabaria sendo cadastrada com
 diversas grafias. O mesmo vale para os bairros: aqui em Porto Alegre
 tem um bairro chamado MONT SERRAT que, sem um cadastro de CEP (ou
 equivalente), seria preenchido de diversas maneiras criativas pelos
 usuários.

        Entendo bem isso e utilizo, mas sempre deixo aberto para o meu cliente
 poder mudar, até porque ruas mudam de nome e bairros também. Meu cep
 hoje 29092170 antes estava como sendo bairro Santa Terezinha, mas um
 outro bairro cresceu muito e os correios resolveram juntar todo mundo.
 Hoje este cep é do bairro Jardim Camburi.

Não apenas isso: a maioria das cidades não tem CEP por logradouro.

        A discussão é sobre o cep ser uma chave natural e eu estou tentando
 mostrar ele não é porque o significado dele muda toda a hora.

Com as UF também é assim, agora querem separar o Pará em vários
estados. Mas isso não é motivo para ter um id_estado artificial ao
invés da sigla como chave primária.


        Uma entidade com um único atributo faz com que ela se confunda com os
 valores atribuídos.

Não lembro quem falou nisso. Eu falei apenas em usar como PK.

        Colocar M para Masculino e F para feminino é tão feio quanto 0 para
 Masculino e 1 para Feminino, porque em ambos os casos você criou um id
 para indicar o sexo, apenas mudou o tipo deste id. O fato de ser a
 primeira letra facilita a visualização do DBA, mas não aumenta ou reduz
 a complexidade das query's a não ser que você vá apresentar para o
 usuário final apenas a letra M ou F.

M e F podem não apenas ser mostrados ao usuário: eles não requerem um
JOIN para saber o sexo.

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

Re: [pgbr-geral] Modelagem (era: Função Update or Insert)

Em 14 de outubro de 2011 16:55, Shander Lyrio
shan...@nucleo45.com.br escreveu:

        Aí é onde quero chegar, a sigla do estado nada mais é do que um id
 (intrínseco já que estamos acostumados). O mesmo para regiões, ao invés
 de usar um id 1, 2, 3, usamos um NE, SE que é mais representativo.

Mas tem gente que acha que mesmo assim é preciso um id_estado
integer (ou serial) como PK.


 M e F podem não apenas ser mostrados ao usuário: eles não requerem um
 JOIN para saber o sexo.

        Os seus clientes, os meus clientes ou qualquer cliente? Não existe
 verdade absoluta, e eu já tive cliente, Banco inclusive, que queria M -
 Masculino no relatório. Obviamente isto não serve de nada, não agrega e
 ainda gasta tonner, mas o cliente pagou para ser feito deste jeito. Ah,
 já ia esquecendo, ele também pediu uma tela para cadastro de Sexos.

Estou falando que sou contra uma tabela assim:
CREATE TABLE sexo (id_sexo integer primary key, desc_sexo text);

Mas não sou contra uma tabela assim:
CREATE TABLE sexo (id_sexo char(1) primary key, desc_sexo text);

Aqui um CREATE DOMAIN ou um CHECK poderia ajudar. Veja que no segundo
caso, acima, o seu cliente poderia ser atendido perfeitamente sem a
criação de uma chave artificial numérica e sua respectiva SEQUENCE.

        Esse tipo de afirmação demonstra o maior defeito dos sistemas de hoje
 em dia. Eles são feito por programadores para programadores e não para
 usuários. Eu entendo da mesma forma que você disse, mas acredite quando
 digo nem todos os usuários finais de sistema entenderiam. Nunca
 subestime a ignorância de um usuário.

A ignorância do usuário, por mais infinita que seja, deve afetar no
máximo a UI -- nunca o modelo. Não aconselho ninguém a deixar que seus
clientes interfiram na sua modelagem.

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

Re: [pgbr-geral] Função Update or Insert

Em 10 de outubro de 2011 16:10, Fabrízio de Royes Mello
fabriziome...@gmail.com escreveu:


 Todavia, melhor resolver mesmo na sua aplicação. Na minha visão,
 tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar
 erro.


 +1  (mas sei que cada caso é um caso)


Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz
nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE.
No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro.

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

Re: [pgbr-geral] Função Update or Insert

Em 13 de outubro de 2011 11:49, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
 2011/10/13 Alexsander Rosa alexsander.r...@gmail.com:

 Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz
 nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE.
 No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro.

 Pois é, e o código tem de capturar o NOT FOUND como qualquer outro
 erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o
 que fôr correto no caso.

Sintaxe do MERGE:

MERGE INTO table_name USING table_reference ON (condition)
  WHEN MATCHED THEN
  UPDATE SET column1 = value1 [, column2 = value2 ...]
  WHEN NOT MATCHED THEN
  INSERT (column1 [, column2 ...]) VALUES (value1 [, value2 ...

Fonte: http://en.wikipedia.org/wiki/Merge_%28SQL%29

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

Re: [pgbr-geral] Função Update or Insert

Em 13 de outubro de 2011 13:57, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
 2011/10/13 Shander Lyrio shan...@nucleo45.com.br:

        ORM não resolve todos os males do mundo, ele resolve a grande maioria
 deles, mas não todos. Para mim, insert, update e delete é 99% por conta
 do ORM porque é quase sempre a mesma coisa.

 Non sequitur.  De qualquer maneira, ORM cria mais problemas que
 resolve.  O problema é menos grave com ORMs relativamente bons como o
 SQL Alchemy, e mais com nojentos como o Hibernate, mas sempre existe.


Na minha opinião um ORM só é útil em telas de cadastro extensas, onde
fica mais fácil preencher as propriedades de um objeto e depois
simplesmente executar um Save() e deixar o OPF se virar pra ver se vai
usar INSERT ou UPDATE, ou ainda quais propriedades vai precisar
alterar e quais pode omitir, etc. OK, o OPF provavelmente vai dar um
SELECT * FROM tabela WHERE chave = x e pegar a tupla inteira, mas
numa tela de cadastro isto é razoável -- se a chave não for
obrigatoriamente um ID serial artificial, evidentemente. Ainda acho
mais fácil fazer um cadastro de cliente desta maneira do que montar
um SQL dinamicamente, por exemplo.

No entanto é preciso ter cuidado e usar o OPF apenas nas telas de
cadastro. Não dá pra usar o OPF numa tela que mostra uma LISTA de
objetos buscados com SELECT *, isto gera um tráfego imenso e
desnecessário. Nestes casos sempre é melhor usar uma VIEW que retorna
apenas o que vai aparecer na tela -- aliás esta é uma regra aqui na
Rednaxel: somente popule listas com views e somente coloque nas views
dados que efetivamente aparecem na tela.

De resto, damos preferência para stored procedures que fazem coisas
como emite_nota, baixa_estoque, etc. Com isso as regras de negócio
ficam no BD e podem ser acessadas por aplicações standalone, console,
web, mobile, etc de forma transparente.

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

Re: [pgbr-geral] Função Update or Insert

Em 13 de outubro de 2011 15:44, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
 2011/10/13 Shander Lyrio shan...@nucleo45.com.br:

        O que seria chave natural para um cadastro de clientes?? cpf se for
 física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa
 e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento
 chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é
 o caso de um colega do sul que presta serviço à escolas que se não me
 engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes.

 Sim, e a conclusão sempre foi a mesma: em última instância, a chave
 natural pode vir a ser a tabela toda, excluídos atributos artificiais.
  Se nem isso identificar, então a base de dados será inconsistente.


Discordo do uso indiscriminado de chaves artificiais, isso traz mais
malefícios do que benefícios. No entanto, na minha opinião o código
do cliente não é uma chave artificial, pois ele aparece fora da
aplicação. Nas nossas contas de luz, telefone, etc está impresso nosso
número de cliente, por exemplo. Da mesma forma, o número do pedido
também é relevante fora da aplicação, vem do tempo em que os
comerciantes preenchiam à mão talões numerados mecanicamente (na
gráfica). Essa é uma realidade que existe desde o início do século
passado, temos que levar isto em consideração.

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

Re: [pgbr-geral] Configurando Timezones por databases

O mais simples é isso mesmo, o usuário informa sua timezone. Num ERP
isto pode ser implícito, o usuário pode ser cadastrado com uma TZ fixa
ou a TZ pode ser associada ao servidor onde ele está se logando. Um
funcionário do operacional pode nem saber que existe TZ e esta ser
fixa no seu cadastro; um usuário gerencial pode informar em que filial
ele quer se logar e o sistema pegar a TZ dela.

Em 13 de outubro de 2011 17:50, Shander Lyrio
shan...@nucleo45.com.br escreveu:

 Em 13-10-2011 16:16, Pedro Ivo Bispo França escreveu:
 Pessoal, então se em uma aplicação WEB não tem como solicitar do browser
 a localização do usuário, então nos resta pré-cadastrar se um estado
 está ou não utilizando o horário de verão e setar o timezone da sessão
 de acordo com esta informação. Correto?

        Acredito que sim, infelizmente, nem pelo ip você consegue uma
 informação fiável do estado em que o usuário está se conectando.

        Aqui temos trabalhado desta forma há 4 anos sem problemas. Também é a
 forma utilizada pela maioria, senão todos os sites de CMS ou foruns
 internacionais, no momento do cadastro do usuário é você informa sua
 timezone.



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

Re: [pgbr-geral] Netiqueta (Era: Atualizacao 9.1.0 para 9.1.1)

2011-10-10 Por tôpico Alexsander Rosa

Em 9 de outubro de 2011 23:13, Euler Taveira de Oliveira
eu...@timbira.com escreveu:


 É fato que temos que investir na educação dos usuários (leitura das regras é
 um bom começo); principalmente a questão do fluxo das conversas (responder no
 contexto -- abaixo das afirmações ou perguntas). Ainda hoje algumas pessoas
 pensam que a lista de discussão é o mesmo que um fórum que envia emails.


Eu participo de várias listas de emails há décadas (no Brasil e no
exterior) e a lista mais netiquette nazi é esta aqui. Faz tempo que
não vejo ninguém reclamando nas listas gringas sobre HTML ou posting
style [1]. Por exemplo: não sei se em pleno 2011, com banda larga
abundante, ainda faz sentido proibir HTML -- ainda mais numa lista
onde código-fonte seguidamente aparece nas mensagens.

[1] http://en.wikipedia.org/wiki/Posting_style

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

Re: [pgbr-geral] Usar campo criado no SELECT no WHERE

2011-09-30 Por tôpico Alexsander Rosa

SELECT * FROM (SELECT codigo, (valor1 + valor2) AS total FROM tabela) as foo
WHERE total  7

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

Re: [pgbr-geral] Sincronizar dados

2011-09-22 Por tôpico Alexsander Rosa

2011/9/22 Euler Taveira de Oliveira eu...@timbira.com

 On 21-09-2011 23:54, Antonio Cesar wrote:
  Pessoal, estou desenvolvendo o PAF-ECF e no requisito III pede para o
 programa
  roda em stand alone.
 
  O pergunta é como sincronizo algumas tabela do banco de dados. copiar de
 uma
  maquina para outras
 
 Replicação baseada em gatilhos (vide Slony, Londiste, et al) [1].


 [1]

 http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling#Replication



Não sei se ele precisa do PostgreSQL no PDV, onde nem mesmo haverá acesso
concorrente. Na ponta até um DBF serve, é só pra manter funcionando em caso
de queda de conexão.


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

Re: [pgbr-geral] Sincronizar dados

2011-09-22 Por tôpico Alexsander Rosa

Em 22 de setembro de 2011 15:47, Euler Taveira de Oliveira 
eu...@timbira.com escreveu:

 On 22-09-2011 14:02, Alexsander Rosa wrote:
  Não sei se ele precisa do PostgreSQL no PDV, onde nem mesmo haverá acesso
  concorrente. Na ponta até um DBF serve, é só pra manter funcionando em
 caso de
  queda de conexão.
 
 É mais fácil ter PostgreSQL nas duas pontas para não complicar a
 transferência
 de dados. Além disso, o PostgreSQL não é tão pesado para justificar o uso
 de
 outro SGBD ou solução de armazenamento temporário.


Faça uma pesquisa: visite alguns supermercados e verifique a configuração
das estações de PDV. Na automação comercial é preciso tomar cuidado, é comum
um supermercado de bairro ter 10 caixas com Windows 98 funcionando bem há
anos. Chegar com um sistema novo que requer upgrade generalizado nem sempre
é visto com bons olhos.


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

Re: [pgbr-geral] Distribuição de Carga de Dados.

2011-09-19 Por tôpico Alexsander Rosa

Em 16 de setembro de 2011 10:42, JotaComm jota.c...@gmail.com escreveu:


 Em 15 de setembro de 2011 18:10, Hugo Bastos Bucker 
 hbbuc...@gmail.comescreveu:


 Bom... pelo menos eu não tenho visto muitas tabelas particionadas
 rodando


 Eu tenho um sistema que faz uso intenso de tabelas particionadas.  Se
 quiser mais pode conversar comigo.


Minha maior dúvida sobre o particionamento é quanto ao processo de
manutenção ao longo dos anos.
A única maneira é usar scripts rodando no CRON para criar novas tabelas e
atualizar os triggers?
Ou existe algum jeito mais limpo, usando alguma feature do próprio banco
ou algo assim?

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

Re: [pgbr-geral] [ajuda] registro novo em tabela com auto incremento(tabela importada)

2011-09-06 Por tôpico Alexsander Rosa

setval('nome_da_sequence',valor);

Exemplo:
Tabela produto coluna codigo serial, por default a sequence fica
produto_codigo_seq.

setval('produto_codigo_seq',(select max(codigo) from produto) );

Em 6 de setembro de 2011 16:03, rogerio dandrea rolemo...@gmail.comescreveu:

 Bom estou com uma tabela que foi criada e depois teve seus dados importados
 de um arquivo csv. acontece que na hora que vou inserir um registro novo ele
 da erro de unicidade do campo onde esta a chave primaria(ID)
 a cada nova tentativa ele vai adicionando um ao valor, mas como o valor já
 contem um valor adicionado dá erro de unicidade.
 como setar o ponteiro para o ultimo registro inserido para que isto não
 ocorra?



-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
___
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 add column

2011-08-30 Por tôpico Alexsander Rosa

Em 29 de agosto de 2011 23:24, Fabiano Machado Dias 
fabi...@wolaksistemas.com.br escreveu:

 Em 29/8/2011 23:01, Leandro Guimarães Faria Corce DUTRA escreveu:
  Le 2011-A-29  22h33, Thiago Godoi a écrit :
Após essa carga… adicionei um campo… bigserial, com o comando:
 
  ALTER TABLE X ADD COLUMN Y BIGSERIAL;
  Aí vem a velha pergunta… para quê?  Geralmente, uma adição dessas é
  porque não se percebeu ou declarou uma chave natural.
 

 Mas não respondeu a pergunta dele! Aliás, como sempre né Leandro?!


CQD ?

:-)

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

Re: [pgbr-geral] PostgreSQL Virtualizado

2011-08-19 Por tôpico Alexsander Rosa

Homem-hora ou Homem-mês?

Em 19 de agosto de 2011 13:32, Guimarães Faria Corcete DUTRA, Leandro 
lean...@dutras.org escreveu:

 2011/8/19 Roberto Mello roberto.me...@gmail.com:
  Não existe bala mágica.

 Como já dizia o mítico homem‐hora, tio Frederico Córregos…



-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
___
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 do campo

2011-08-19 Por tôpico Alexsander Rosa

Em 19 de agosto de 2011 13:21, Marcos Fabricio Corso 
marcos.co...@ablsystem.com.br escreveu:


 sim preciso alterar o tamanho do campo da tabela, e urgente ainda .


Precisa alterar o tamanho do campo ou o tamanho do nome do campo, afinal?

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

Re: [pgbr-geral] Alterar campo databela

2011-08-16 Por tôpico Alexsander Rosa

Aconselho a salvar o fonte das views no seu controle de versão, porque o
PG traduz tudo deixando bem difícil de ler. Toda vez que mexo no banco,
costumo dar um pg_dump schema-only pra colocar no SVN. Isso funciona bem
para as stored procedures mas não para as views -- o PG coloca tudo no
formato tabela.coluna e acaba com qualquer identação que você tenha usado.

Em 15 de agosto de 2011 22:37, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 Em 15 de agosto de 2011 20:39, Pedro B. Alves 
 pedroalve...@gmail.comescreveu:

 Pessoa, como eu faço para alterar um capo de varchar(50) para
 varchar(200) em uma tabela, sendo que este campo está sendo usado em
 algumas views no banco de dados?

 Versao 8.2


 Simples:

 1) DROP VIEW ...

 2) ALTER TABLE tabela ALTER COLUMN campo TYPE varchar(200);

 3) CREATE VIEW ...

 --
 Fabrízio de Royes Mello
 Consultoria/Coaching PostgreSQL
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
  Twitter: http://twitter.com/fabriziomello


 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Novato com uma dúvida , campo PK sendo GUID

2011-07-20 Por tôpico Alexsander Rosa

Em 20 de julho de 2011 01:54, Euler Taveira de Oliveira
eu...@timbira.comescreveu:

 Em 20-07-2011 01:11, Alexsander Rosa escreveu:
  É muito mais fácil identificar o pedido 876232 do que o pedido João da
  Silva + CPF + timestamp (como disse o Fabrizio, o João da Silva pode
  fazer mais de um pedido). E mais: todo mundo sabe escrever João da
  Silva após ter ouvido o nome por telefone, mas quero ver os operadores
  do call center procurando o pedido do Sr. Washington Vizzotto e
  digitando Uóchintom ou Visoto, como acontece no mundo real.
 
 Isso é relativo. Se a interface apresentar os pedidos do João da Silva é
 fácil
 identificá-los (você deve estar imaginando que o usuário tenha que informar
 todos os campos mas pode ser algo como pedidos em aberto e na data de
 ontem. O
 usuário só teria o trabalho de conferir se os campos batem com o que o
 usuário
 informou). Nada contra números, só acho que expô-los em excesso atrapalha
 mais
 do que ajuda. Quer um exemplo? Números de protocolo de operadoras de
 telefonia. Há pelo menos uns 10 a 15 dígitos e se você anotar um dígito
 errado...


Números de pedido fazem parte do mundo real desde antes da invenção do
computador. Os comerciantes compravam blocos numerados e os usavam para
anotar os pedidos dos clientes. Este tipo de talão de pedidos existe até
hoje, qualquer gráfica que faz talões de notas fiscais também faz talões de
pedidos. Se você derramasse café no talão e inutilizasse 10 folhas, a
numeração ficava com um buraco -- isso nunca foi um problema. *Número de
pedido é chave natural* desde antes do primeiro software de automação
comercial.

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

Re: [pgbr-geral] Novato com uma dúvida , campo PK sendo GUID

2011-07-20 Por tôpico Alexsander Rosa

Em 20 de julho de 2011 11:38, Johnny Chaves jfcha...@brdados.com.brescreveu:


 *Se* existir o tal talão isso é verdade, já passei por isso, e enquanto a
 empresa usava as Fichas Brancas como eram chamadas, funcionava bem.
 Quando decidiram eliminar as fichas e manter a mesma forma de trabalho, fui
 eu
 quem perdeu noites de sono, pra fazer funcionar, e, depois com medo de
 algum
 paciente ficar sem (ou receber de outro) seus resultados de exames.

 Ou seja *se existir* tal controle, *é* um atributo do que está sendo
 modelado,
 e deve ser usado, caso contrario é um quebra galho, que usamos por
 enquanto.



-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
attachment: 1942.jpg___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Novato com uma dúvida , campo PK sendo GUID

2011-07-20 Por tôpico Alexsander Rosa

Em 20 de julho de 2011 13:45, Euler Taveira de Oliveira
eu...@timbira.comescreveu:

 Em 20-07-2011 09:56, Alexsander Rosa escreveu:
  *Número de pedido é chave natural* desde antes do primeiro software de
  automação comercial.
 
 E quem disse que ao automatizar não podemos mudar o processo? Todos os
 requisitos mudam (vide engenharia de requisitos) ao longo do tempo.


Invoice de 1966: http://www.early-mustang.com/charles/66_order/invoice.jpg
Claro que pode mudar... resta saber se remover o número do pedido é uma
mudança pra pior ou pra melhor.


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

Re: [pgbr-geral] Novato com uma dúvida , campo PK sendo GUID

2011-07-19 Por tôpico Alexsander Rosa

Em 19 de julho de 2011 17:49, Johnny Chaves jfcha...@brdados.com.brescreveu:


 Alexsander, não quero ser grosso, mas como disse em outra mensagem esse
 assunto já foi discutido dezenas de vezes na lista, mais na antiga do yahoo
 do
 que nessa, e os argumentos (racionais) que você apresenta já foram
 apresentados muitas vezes.


Sim, eu sei, e se você olhar no arquivo da lista tem várias mensagens
*minhas* sobre o assunto.

A questão é: cada um faz o que quiser com as bases que administra. Se alguém
quiser usar CPF ou CNPJ como PK de pessoa (ou qualquer especialização como
cliente ou fornecedor) em nome da pureza teórica, pode usar que estou me
lixando.

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

Re: [pgbr-geral] Novato com uma dúvida , campo PK sendo GUID

2011-07-19 Por tôpico Alexsander Rosa

Comentários no texto.

Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
eu...@timbira.comescreveu:

 Em 19-07-2011 17:49, Johnny Chaves escreveu:
  Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
  2011/7/11 Alexsander Rosaalexsander.r...@gmail.com:
  As pessoas estão acostumadas a receber um número de pedido quando
  compram alguma coisa.
 
 E por que não o pedido do João da Silva + CPF? Acho que seria muito mais
 elegante o funcionário dizer: Seu João da Silva? Aqui está o seu pedido. Do
 que: Número? 7..9..5..7..2..3..9..5..8..2..3..7. Aqui está o seu pedido.


É muito mais fácil identificar o pedido 876232 do que o pedido João da
Silva + CPF + timestamp (como disse o Fabrizio, o João da Silva pode fazer
mais de um pedido). E mais: todo mundo sabe escrever João da Silva após
ter ouvido o nome por telefone, mas quero ver os operadores do call center
procurando o pedido do Sr. Washington Vizzotto e digitando Uóchintom ou
Visoto, como acontece no mundo real.


 (...)
 De qualquer forma, isso não garante que nunca haverá buracos; haverá mas a
 aplicação irá tampá-los ao longo do tempo.


Buracos na numeração de códigos de pedidos e pessoas raramente são problema.
Mesmo o número de nota fiscal (que não é um mero identificador interno,
visto que é exigido pelo fisco) de uma NF-e pode ser pulado, bastando para
isto inutilizar a numeração. Se não há exigência legal (como NF e empenho),
não é preciso se preocupar com buracos na numeração.



 Expor um número identificador que não faz muito sentido fora da aplicação é
 um
 erro. Na verdade, esse identificador deveria ficar restrito ao modelo
 físico
 do SGBD (argh, oids) mas não é o que ocorre na prática (a parcela de culpa
 fica dividida entre o padrão SQL e o desenvolvedor).


Eu concordo que expor um identificador que não faz sentido fora da aplicação
é um erro, mas fica a pergunta: o número de um pedido faz ou não faz sentido
fora da aplicação, tanto para quem vende quanto para quem compra?


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

Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID

2011-07-13 Por tôpico Alexsander Rosa

Em 12 de julho de 2011 13:02, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

  (...) CPF e CNPJ, por outro lado, podem ser chaves naturais (compostas,
 se

 necessário), mas não são boas chaves primárias pelos motivos expostos
 anteriormente.

 Motivos esses todos inválidos.


1) CPF compartilhado por marido e esposa. O marido é um cliente, a esposa é
outro cliente. Se a chave primária simples for o CPF, um deles não poderá se
cadastrar. Neste caso é melhor usar uma chave artificial como código do
cliente.

2) CNPJ compartilhado por vários órgãos públicos (principalmente nas áreas
de Saúde e Educação). Se a chave primária simples for o CNPJ, somente um
deles poderá se cadastrar. Para uma empresa que vende suprimentos para
hospitais ou escolas isso significaria a falência. Neste caso é melhor usar
uma chave artificial como código do cliente.

3) Se o código do cliente for inaceitável para as regras de negócio, uma
possível maneira de manter o purismo e contonar a imperfeição do mundo
real seria fazer a chave primária ser composta -- por exemplo, CPF/CNPJ +
número sequencial. No mundo real das aplicações comerciais, no entanto, a
regra é trabalhar com código de cliente -- esta chave composta raramente
seria necessária.

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

Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID

2011-07-13 Por tôpico Alexsander Rosa

Em 13 de julho de 2011 13:28, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2011/7/13 Alexsander Rosa alexsander.r...@gmail.com:
 
  1) CPF compartilhado por marido e esposa. O marido é um cliente, a esposa
 é
  outro cliente. Se a chave primária simples for o CPF, um deles não poderá
 se
  cadastrar. Neste caso é melhor usar uma chave artificial como código do
  cliente.

 De novo confusão.  Se código do cliente for requisito de negócio, não
 será artificial; e, de qualquer maneira, o uso de um código não
 garante unicidade, continua sendo necessário declarar pelo menos uma
 chave natural.

 O mesmo vale para seu item (2)


  3) Se o código do cliente for inaceitável para as regras de negócio,
 uma
  possível maneira de manter o purismo e contonar a imperfeição do mundo
  real seria fazer a chave primária ser composta -- por exemplo, CPF/CNPJ +
  número sequencial. No mundo real das aplicações comerciais, no entanto, a
  regra é trabalhar com código de cliente -- esta chave composta
 raramente
  seria necessária.

 Conceitualmente não importa qual seria a chave primária, desde que
 haja ao menos uma chave declarada que garanta a unicidade.  Isso
 porque conceitualmente não faz a menor diferença qual das chaves é a
 primária.



Assim fica difícil manter o debate, você argumenta contra seus próprios
espantalhos... :-)
Encerrei por aqui, siga usando CPF e CNPJ como chave primária simples se
quiser.

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

Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID

2011-07-12 Por tôpico Alexsander Rosa

Comentários no texto:

Em 11 de julho de 2011 17:50, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
  Sim, obviamente, mas quem usaria CPF + NOME como chave primária de
 CLIENTE
  (ou PESSOA)?

 Péssimo exemplo, visto que essa definitivamente não é uma chave natural
 válida.


O exemplo CPF + NOME como chave natural foi sugerido aqui mesmo neste
tópico, algumas mensagens atrás: portanto, as chave naturais incluirão algo
mais, como endereço, nome… Também acho estranho. [1]


  Chaves primárias como código de cliente e número de pedido, compostas
 ou
  não, são quase inevitáveis.

 Quase, mas nem sempre.  E muitas vezes por limitações tecnológicas
 arbitrárias, não motivos conceituais válidos.


Na minha opinião, não se trata de limitação tecnológica, mas de regra de
negócio.


  As pessoas estão acostumadas a receber um número de pedido quando
 compram
  alguma coisa.

 Se é uma definição de negócio, deixa de ser uma chave artificial e
 passa a ser natural.  Aí a única questão passa a ser definir uma chave
 natural alternativa.


Exatamente! Código de cliente e número de pedido nascem como artificiais mas
se tornam, ao adentrar o mundo real, chaves naturais. E mais: estas são
chaves naturais que podem, também, ser chaves primárias. CPF e CNPJ, por
outro lado, podem ser chaves naturais (compostas, se necessário), mas não
são boas chaves primárias pelos motivos expostos anteriormente.

[1]
http://listas.postgresql.org.br/pipermail/pgbr-geral/2011-July/025651.html

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

Re: [pgbr-geral] PARA AUDITORIA

2011-07-12 Por tôpico Alexsander Rosa

Eu uso esta solução de triggers nas tabelas que PRECISAM de auditoria.
Raramente você vai precisar auditar TODAS as tabelas.

Em 11 de julho de 2011 17:34, Flavio Henrique Araque Gurgel 
fha...@gmail.com escreveu:

 - triggers nas tabelas que precisam de auditoria, essas triggers podem
 gravar alterações numa tabela de auditoria, lembrando que existe uma
 penalidade de performance aí. Já implementei auditoria assim.

 []s
 Flavio Gurgel


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

Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID

2011-07-11 Por tôpico Alexsander Rosa

No meu ERP uso um parâmetro digitos_empresa (geralmente 4) para montar a
chave. Exemplo: o 1º cliente cadastrado na filial 7 fica com código 10007
que é mostrado como 1/7 no sistema. O cliente nº 357 da filial 24 fica com
código 3570024 e assim por diante. Como já foi discutido aqui antes, a chave
artificial vira natural quando sobe até o mundo real -- o número do
cliente aparece nos orçamentos, pedidos e na NF-e; também é comum o cliente
telefonar e dizer sou o 2467/2 por exemplo.

Na minha opinião, a entidade cliente (ou pessoa como eu prefiro modelar)
fica melhor modelada com um código sequencial. Chaves naturais existem mas
não são suficientes. Por exemplo, nem CPF nem CNPJ servem como PK: o CPF é
reusado alguns anos depois do falecimento do titular e muitos órgãos
ṕublicos compartilham o mesmo CNPJ -- por exemplo, TODAS as escolas
estaduais do RS usam o CNPJ da Secretaria da Educação do estado.

Em 9 de julho de 2011 06:41, Pablo Sánchez phack...@gmail.com escreveu:

 Pelo que estou vendo vc quer trabalhar com uma aplicação off-line que
 quando entre on-line faça o upload das informações trabalhadas localmente,
 correto?

 O campo serial nada mais é que uma constraint ON INSERT que busca o nextval
 da sequence a ele associado. Você poderia simplesmente criar uma constraint
 que criasse um valor para vc, não necessariamente aleatório, poderia ser um
 identificador composto por id do usuário que criou, mais um identificador
 único de instalação (sei lá, inventa), mais um sequence local só para isso.
 Aí, quando criasse ficaria algo como

 10/INST10002-1

 Ou qualquer coisa assim. O lance é que se resolve simplesmente com uma boa
 pensada em como compor sua chave, e criando a constraint.




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

Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID

2011-07-11 Por tôpico Alexsander Rosa

Há inúmeros casos de CPF duplicados emitidos legalmente, já vi advogados
comentando sobre isso, é uma dor de cabeça. Hoje em dia parece que é tudo
centralizado e isso não deve mais ocorrer.

De qualquer forma, na minha opinião é mais correto usar código do cliente
ao invés de CPF ou CNPJ. Não dá pra confiar na competência do governo em
garantir unicidade.

Em 11 de julho de 2011 11:35, Eduardo Az - EMBRASIS 
eduard...@embrasis.com.br escreveu:

   Alex
 Aonde vc teve esta informação???
 É equivocada, pois, não podem re-usar um cpf, cnpj, nem rg! Isto abre
 precedente para fraude!!!
 Detalhe: CNPJ pode repetir os números iniciais, porem, os últimos números
 são as filiais, por exemplo: 01.222.334/0001-22,.../0002-34, /0003-44 e
 assim por diante. Mesmo se uma filial fechar, aquele numero fica
 inutilizado.

 Eduardo Az
 Dep.TI
 EMBRASIS
 +55(11)8125-3845 TIM
 eduard...@embrasis.com.br

  *From:* Fellipe Henrique felli...@gmail.com
 *Sent:* Monday, July 11, 2011 10:56 AM
 *To:* Comunidade PostgreSQL Brasileirapgbr-geral@listas.postgresql.org.br
 *Subject:* Re: [pgbr-geral]Novato com uma dúvida, campo PK sendo GUID




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

Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID

2011-07-11 Por tôpico Alexsander Rosa

Sim, obviamente, mas quem usaria CPF + NOME como chave primária de CLIENTE
(ou PESSOA)?
Chaves primárias como código de cliente e número de pedido, compostas ou
não, são quase inevitáveis.
As pessoas estão acostumadas a receber um número de pedido quando compram
alguma coisa.

Em 11 de julho de 2011 17:31, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
  Sim, mas o OP estava falando sobre PK; o meu argumento é que CPF e CNPJ
 não
  servem como PK há duplicidade nos dois: esposas com CPF de maridos,
 escolas
  estaduais com CNPJ da Secretaria de Educação, etc. Com algo mais (nome,
  etc) são excelentes chaves naturais -- mas não PK.

 Me parece que está havendo uma grande confusão entre chave simples e
 chave primária.  A chave primária *não precisa* ser simples, pode ser
 _composta_!


 --
 Skype:leandro.gfc.dutra?chat   Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org
 +55 (11) 9406 7191  MSNIM:chat?contact=lean...@dutra.fastmail.fm
 sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803
 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos

2011-06-28 Por tôpico Alexsander Rosa

Comentei lá, com uma sugestão de modificação (para evitar um divisão por
zero).

Em 27 de junho de 2011 19:38, Fábio Telles Rodriguez fabio.tel...@gmail.com
 escreveu:

 Nome complicado, mas espero ter achado uma solução interessante.


 http://www.midstorm.org/~telles/2011/06/27/arrumando-a-ordem-das-colunas-em-indices-compostos/

 Se alguém tiver alguma sugestão para melhorar, eu agradeço.
 Comentários também são bem vindos.



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

Re: [pgbr-geral] Modelagem: funcionário x dependente

Tudo isso porque eu queria evitar que o filho de um casal onde ambos são
funcionários tivesse dois registros no sistema... :-)

Em 26 de maio de 2011 09:11, ivo nascimento ian...@gmail.com escreveu:

 fato.
 vamos pra proxima entao.
 []

 Em 26/05/2011 09:07, Flavio Henrique Araque Gurgel fha...@gmail.com
 escreveu:


 Em 26 de maio de 2011 01:44, Euler Taveira de Oliveira
 eu...@timbira.com escreveu:


  Essa discussão chave natural x artificial faz-me lembrar do Dilbert [1].
 Toda
  vez que vejo um s...
 Euler, este quadrinho encerra com chave de ouro esta thread :)
 Acho que estamos discutindo filosofia de AD, passou do escopo PostgreSQL.

 []s

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql...




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

Re: [pgbr-geral] Modelagem: funcionário x dependente

Não. Na prática é uma situação um tanto quanto rara, esta.

Em 26 de maio de 2011 09:42, Aldemir Vieira alde...@gmail.com escreveu:

 Já se decidiu? Uma pergunta: O dependente sempre terá pai e mãe como
 funcionários?

 2011/5/26 Alexsander Rosa alexsander.r...@gmail.com

 Tudo isso porque eu queria evitar que o filho de um casal onde ambos são
 funcionários tivesse dois registros no sistema... :-)

 Em 26 de maio de 2011 09:11, ivo nascimento ian...@gmail.com escreveu:

 fato.
 vamos pra proxima entao.
 []

 Em 26/05/2011 09:07, Flavio Henrique Araque Gurgel fha...@gmail.com
 escreveu:


 Em 26 de maio de 2011 01:44, Euler Taveira de Oliveira
 eu...@timbira.com escreveu:


  Essa discussão chave natural x artificial faz-me lembrar do Dilbert
 [1]. Toda
  vez que vejo um s...

 Euler, este quadrinho encerra com chave de ouro esta thread :)
 Acho que estamos discutindo filosofia de AD, passou do escopo PostgreSQL.

 []s



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

Re: [pgbr-geral] Modelagem: funcionário x dependente

Casos que o modelo tem que suportar:
- filho em que os dois pais são funcionários
- filho em que um dos pais é funcionário, casado com o(a) pai/mãe deles
- filho em que um dos pais é funcionário, separado do(a) pai/mãe deles, sem
descontar pensão em folha
- filho em que um dos pais é funcionário, separado do(a) pai/mãe deles,
descontando pensão em folha
etc

Em 26 de maio de 2011 10:14, Flavio Henrique Araque Gurgel fha...@gmail.com
 escreveu:

  Não tenho certeza sobre o escopo, mas essas discussões são salutares
  nesta lista, e construtivas da perspectiva onde o DBA deveria,
 (...)

 Se o Léo falou, tá falado. Retiro o que disse e que a discussão prossiga.
 []s
 Flavio
 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelagem: funcionário x dependente

Alguma sugestão?

Em 26 de maio de 2011 11:17, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2011/5/26 Alexsander Rosa alexsander.r...@gmail.com:
  Tudo isso porque eu queria evitar que o filho de um casal onde ambos são
  funcionários tivesse dois registros no sistema... :-)

 Todo problema lógico é fundamental.


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




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
___
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 is not null

2011-05-25 Por tôpico Alexsander Rosa

Coloque um RAISE NOTICE 'XSELECTINCLUIR=%', XSELECTINCLUIR;
E outro RAISE antes do outro EXECUTE, assim você vê como o SQL está
chegando.

Em 25 de maio de 2011 14:59, Juliano Benvenuto Piovezan 
juli...@sinersoft.com.br escreveu:

 XSELECTINCLUIR := 'SELECT '||XINCREMESSAGERAL||' , '||XINCUNIDESTINO||' ,
 '||XINCNUMEROREMESSA||' FROM '||XTABELAINCLUIR||' WHERE
 '||XINCREMESSAGERAL||' = '||XIDSREMESSAS[I]||';';

 EXECUTE XSELECTINCLUIR INTO
 VAIDREMESSAINCLUIR,VAIDDESTINOINCLUIR,VAIDNUMEROREMESSAINCLUIR


 Muito provavelmente o problema se encontra nesse EXECUTE já, e não no *EXECUTE
 XINSERT. *Algum dos campos que você está concatenando é nulo.

 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Modelagem: funcionário x dependente

2011-05-25 Por tôpico Alexsander Rosa

Supondo uma tabela funcionario cuja PK é cpf.

Num primeiro momento pode-se pensar algo assim:
CREATE TABLE dependente (
  cpf bigint not null,
  nome text not null,
  tipo integer,
  primary key(cpf,nome),
  foreign key (cpf) references funcionario(cpf)
  );

Mas este modelo não suporta o caso dos casais que trabalham na mesma empresa
e têm filhos; os filhos ficariam vinculados a apenas um deles. Mesmo que se
mapeasse pelo tipo pra saber quem é o cônjugue-colega, não tem como
garantir que o cônjugue é mesmo pai ou mãe da criança, pode ser um casal com
filhos de casamentos anteriores.

Exemplo:
Pedro (funcionário) é pai de Maria (mãe Fernanda, ex-esposa) e Paula (mãe
Regina, esposa e funcionária).
Regina (funcionária) é mãe de Henrique (pai Roberto, ex-marido) e Paula (pai
Pedro, marido e funcionário).
Fernanda e Roberto poderiam ser funcionários também, para complicar mais um
pouco.

Pensei em algo tipo:
CREATE TABLE dependente (
  cpf_pai bigint not null,
  cpf_mae bigint not null,
  nome text not null,
  tipo integer,
  primary key(cpf_pai, cpf_mae, nome),
  foreign key (cpf) references funcionario(cpf)
  );


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

Re: [pgbr-geral] Modelagem: funcionário x dependente

2011-05-25 Por tôpico Alexsander Rosa

Mas nem todo dependente tem CPF, especialmente crianças.

Em 25 de maio de 2011 16:29, Flavio Henrique Araque Gurgel fha...@gmail.com
 escreveu:

  Pensei em algo tipo:
  CREATE TABLE dependente (
cpf_pai bigint not null,
cpf_mae bigint not null,
nome text not null,
tipo integer,
primary key(cpf_pai, cpf_mae, nome),
foreign key (cpf) references funcionario(cpf)
);

 Se você colocar dois campos referenciando a mesma tabela (no seu caso,
 funcionario) você não terá com forçar a integridade referencial.
 Sugiro fazer uma tabela intermediária:

 CREATE TABLE dependente_funcionario (
 cpf_dependente bigint not null,
 cpf_responsavel bigint not null,
 primary key (cpf_dependente, cpf_responsavel),
 foreign key (cpf_dependente) references dependente(cpf),
 foreign key (cpf_responsavel) references funcionario(cpf)
 );

 Esta tabela faz a cola entre a tabela de dependentes e funcionários.

 []s
 Flavio Gurgel
 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Postgre X Delphi

2011-04-28 Por tôpico Alexsander Rosa

Eu uso o Lazarus e recomendo. Agora há pouco saiu a versão 0.9.30 que está
muito boa.

Em 27 de abril de 2011 16:10, Alexsandro Haag
alexsandro.h...@gmail.comescreveu:

Se quiser migrar definitivamente para software livre dê uma olhada também
no projeto Lazarus (Delphi Like), mas baseado no FreePascal e não no Pascal
da Borland...
A lib ZeosDbo está disponível para ele também.

O site é http://lazarus.freepascal.org

Att.
Alex

Em 27-04-2011 08:21, Marcio escreveu:

Bom dia Alexandre!
Nao há nenhuma maneira de vc trabalhar com “Postgree” e Delphi, por que
“Postgree” simplesmente nao existe.
PostgreSQL esse sim é um banco de dados Robusto, com performance e
escalabilidade que nao deixa a desejar para nenhum dos outros DB’s, sem
deixar de lado
varias outras qualidades.
Uma Leitura na documentação sempre é recomendada para quem está
começando...e para os experientes também...
Voce pode usar Zeos ou a ferramenta da Vitavoom(paga).
Ambas oferecem ótimos resultados.
Abraço.

*From:* Alexandre S Gondim treiname...@magosoftware.com.br
*Sent:* Tuesday, April 26, 2011 6:28 PM
*To:* pgbr-geral@listas.postgresql.org.br
*Subject:* [pgbr-geral] Postgre X Delphi

Ola pessoal

Sempre desenvolvi sistemas no Delphi com a famigerada BDE e algumas vezes
com o Firebird. Ouvi maravlihas sobre o Postgre, velocidade, etc. Estou com
dificuldade em começar. Tenho dúvidas sobre instalação, como configurar os
terminais, etc.

Alguem tem alguma dica de livros, etc, de como trabalhar com o Postgree no
Delphi ?

*Abraços*
**
*Alexandre S Gondim*

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

___
pgbr-geral mailing
listpgbr-ge...@listas.postgresql.org.brhttps://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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [Fabrízio de Royes Mello] PGBR2011 - Conferência Nacional PostgreSQL (3-4 Nov...

2011-04-11 Por tôpico Alexsander Rosa

Foi nessa que eu fui, me achei na foto com a camiseta pólo azul que vendiam
lá. Curiosamente, quem me avisou do evento e única pessoa que eu conhecia
previamente era o David Fetter, com quem eu falava (e ainda falo)
seguidamente no canal #postgresql do Freenode.

Em 8 de abril de 2011 14:52, Euler Taveira de Oliveira
eu...@timbira.comescreveu:

 Em 08-04-2011 13:22, Alexsander Rosa escreveu:
  De que ano são as fotos do banner? Posso ter me achado numa delas...
 rsrsrs
  http://pgbr.postgresql.org.br/2011/imgs/c2007.jpg
 
 O ano está indicado na foto: 2007. Essa foto é da primeira conferência que
 aconteceu em São Paulo, SP.



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

Re: [pgbr-geral] [Fabrízio de Royes Mello] PGBR2011 - Conferência Nacional PostgreSQL (3-4 Nov...

2011-04-08 Por tôpico Alexsander Rosa

De que ano são as fotos do banner? Posso ter me achado numa delas... rsrsrs
http://pgbr.postgresql.org.br/2011/imgs/c2007.jpg

Em 8 de abril de 2011 08:07, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:

 O PGBR (antes conhecido como PGCon Brasil) é o maior evento sobre
 PostgreSQL das Américas: em 2009 e 2008, o evento trouxe mais de 300
 profissionais de TI e, em 2007, mais de 200. Em 2011, serão 3 salas
 simultâneas com tutoriais, palestras e mesas de alto nível, contando com
 desenvolvedores nacionais e internacionais do PostgreSQL além de
 profissionais renomados no mercado brasileiro.


 Venha conhecer de perto uma das comunidades de Software Livre que mais
 cresce no Brasil e no mundo que conta com o suporte de empresas de grande
 porte como CAIXA, Skype, BASF e Cisco. Conheça alguns dos maiores casos de
 sucesso brasileiros em órgãos públicos e privados, as novidades da versão
 9.1 e o que está previsto para a versão 9.2 do PostgreSQL. Você terá a
 oportunidade também de conhecer técnicas avançadas de montitoramento,
 ajustes de performance, técnicas de replicação, migração, alta
 disponibilidade e muito mais.


 Mais informações no sítio do evento: http://pgbr.postgresql.org.br


 Aproveite também e preencha a nossa pesquisa sobre uso do PostgreSQL no
 Brasil:

 https://spreadsheets.google.com/viewform?formkey=dFNOS0pjUFp3MFM0Y0xWT1RIWUZfRGc6MA


 Cordialmente,

 Fabrízio de Royes Mello
 fabriziomello [at] gmail.com

 --
 Postado por Fabrízio de Royes Mello no Fabrízio de Royes 
 Mellohttp://fabriziomello.blogspot.com/2011/04/pgbr2011-conferencia-nacional.htmlem
  4/08/2011 08:07:00 AM
 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Segurança total em banco de dados

Quem pesquisou colocando site:seusite.com.br levante a mão... o/

Em 30 de março de 2011 13:37, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 Em 30 de março de 2011 13:13, Fábio Telles Rodriguez 
 fabio.tel...@gmail.com escreveu:

 Vejam essa aqui:

 Coloque no Google:
 ext:sql site:com.br

 Ou seja: busque arquivos com a extensão '.sql' em sites com a extensão
 '.com.br'.

 Vejam e o resultado e me digam o que acharam.


 Hehehehe... e depois são as ferramentas que não oferecem segurança
 adequada...

 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello


 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Segurança total em banco de dados

Cadeia por expor quaisquer dados ou apenas por expor dados pessoais de
terceiros?

Em 30 de março de 2011 13:55, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:

 2011/3/30 Fábio Telles Rodriguez fabio.tel...@gmail.com:
 
  Vejam e o resultado e me digam o que acharam.

 Devia dar cadeia…




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

Re: [pgbr-geral] RES: Segurança total em banco de dados

Mas se não há dados pessoais (como nome, CPF, telefone, endereço, etc) qual
seria o crime?
Não sei é piada, mas não acho que tolice ou incompetência devam ser
criminalizados.
Discordo da existência do crime sem vítima, onde nenhum terceiro é
prejudicado.

Em 30 de março de 2011 14:20, Rubens José Rodrigues 
rubens.rodrig...@batistarepresentacoes.com escreveu:

  ... e ou cadeia para quem cometeu estas tolices?







 *De:* pgbr-geral-boun...@listas.postgresql.org.br [mailto:
 pgbr-geral-boun...@listas.postgresql.org.br] *Em nome de *Alexsander Rosa
 *Enviada em:* quarta-feira, 30 de março de 2011 14:14

 *Para:* Comunidade PostgreSQL Brasileira
 *Assunto:* Re: [pgbr-geral] Segurança total em banco de dados



 Cadeia por expor quaisquer dados ou apenas por expor dados pessoais de
 terceiros?

 Em 30 de março de 2011 13:55, Leandro DUTRA leandro.gfc.du...@gmail.com
 escreveu:

 2011/3/30 Fábio Telles Rodriguez fabio.tel...@gmail.com:

 
  Vejam e o resultado e me digam o que acharam.

 Devia dar cadeia…




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

Re: [pgbr-geral] RES: Segurança total em banco de dados

Sim, eu sei. Estes sim podem (ou deveriam) estar cometendo algum crime:
http://www.google.com/search?q=ext%3Asql+site%3Acom.br+cpf

Em 30 de março de 2011 14:45, Alexsandro Haag
alexsandro.h...@gmail.comescreveu:

  Tem dumps de bases inteiras ali. Se procurarmos vamos achar estes dados
 pessoais com certeza.

 Alex





-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
___
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 evitar autenticação trust?

2011-03-02 Por tôpico Alexsander Rosa

Se você quer sigilo, cripografe os dados. Neste caso, mesmo que o root
resolva espiar o que tem no BD, não vai conseguir ver nada.

Em 1 de março de 2011 14:33, Avelino Brun avel...@databrum.com.brescreveu:

   Olá Alexander!

 Como poderemos proteger os dados então pelos motivos que foram citados por
 você?

 Atenciosamente
 Avelino




  *From:* Alexsander Rosa alexsander.r...@gmail.com
 *Sent:* Tuesday, March 01, 2011 12:53 PM
 *To:* Marcelo Silva (IG) marc...@ig.com.br ; Comunidade PostgreSQL
 Brasileira pgbr-geral@listas.postgresql.org.br
 *Subject:* Re: [pgbr-geral]Como evitar autenticação trust?

 Há dois motivos para precisar disso:
 - sigilo (proteção dos dados contra acesso indevido) e
 - licenciamento (proteção do schema contra cópias indevidas)

 A criptografia só protege contra o primeiro caso. Nada impede que um
 administrador interessado em fazer cópias ilegais faça um DUMP do banco, com
 dados criptografados ou não, e instale em outro servidor.

 Em 28 de fevereiro de 2011 12:34, Marcelo Silva (IG) 
 marc...@ig.com.brescreveu:

 Pense o seguinte... a segurança do banco depende da segurança do servidor,
 desta forma presume-se que se o cara tem acesso root ao servidor ele tem
 acesso ao que está nele.
 Existem algumas medidas drasticas a se tomar levando em conta a
 viabilidade,
 por exemplo, se não quer que acessem os arquivos de configurações do
 postgres terá que limitar o acesso as pastas somente ao usuario do
 postgres,
 essa configuração é dor de cabeça, pois as vezes o root precisa ter acesso
 a
 estas pastas pra no caso de ter que reinstalar o postgres e etc... então
 acaba não sendo viavel...
 Agora se o problema é alguém poder ler ou pegar os dados da tua base, você
 poderia gravar tudo encriptado, também não sei se seria o caso... mas são
 coisas a se pensar.

 Se a pessoa tem acesso direto a sua maquina... dificilmente irá conseguir
 bloquear os acessos a base... pois pra cada meio de segurança existem N
 meios de quebrar a segurança quando se tem acesso fisico a maquina.

 Acho que encriptar ainda é a medida mais aconselhavel quando não quer
 que
 alguem leia o que está ali. (claro que os fontes da aplicação que encripta
 deve estar muito bem guardado e longe do servidor) (acaba virando uma
 neorose rsrs )


 Marcelo Silva
 ---



 -Mensagem Original-
 From: Leandro Guimarães Faria Corcete DUTRA
 Sent: Monday, February 28, 2011 12:01 PM
 To: pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] Como evitar autenticação trust?

 On 2011.F.28 11h45, Fa wrote:
 
  Como proteger um banco de dados Postgres contra acesso indevido, sendo
 que
  basta qualquer um alterar
  o arquivo de configuração pg_hba.conf colocando o modo de autenticação
  trust no servidor
  para conseguir acesso total ao servidor Postgres inclusive como
  super-usuário sem informar senha alguma?

 O pg_hba.conf somente pode ser editado pelo administrador, portanto não
 há problema algum.







  ___
 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
 http://rednaxel.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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Operador varchar = int8 no postgreSQL 9

2011-03-01 Por tôpico Alexsander Rosa

Se for no Windows, abra o executável no Ultra-Edit (ou outro editor hexa
de sua preferência) e veja se dá pra consertar o SQL. Dependendo da forma
como eles são montados, pode ser possível. A coisa mais simples seria trocar
os LIKE por = onde for necessário, removendo os % também.

Em 1 de março de 2011 09:20, Marco Aurélio Carvalho Feitosa 
ma...@tj.rr.gov.br escreveu:

 Em 28-02-2011 19:37, Marcal Hokama escreveu:
  
  Date: Mon, 28 Feb 2011 14:02:05 -0400
  From: ma...@tj.rr.gov.br
  To: pgbr-geral@listas.postgresql.org.br
  Subject: Re: [pgbr-geral] Operador varchar = int8 no postgreSQL 9
 
  Em 28-02-2011 13:09, Flavio Henrique Araque Gurgel escreveu:
  Olá a todos.
 
  Ha alguns anos, migrei um sistema legado do MS SQLServer para
 PostgreSQL.
  Esse sistema faz consultas do tipo:
 
  SELECT * FROM organizacional.funcionario WHERE matricula = 989676;
 
  onde matricula é um varchar.
 
  Até a versão 8.1 (que utilizávamos aqui até o mês passado) o SGBD
 aceitava
  comparações varchar = int, bem como int = varchar.
 
  Depois de atualizarmos para versão 9.0.2 esta consulta passou a dar
 erro:
  Error: ERRO: operador não existe: character varying = integer
  SQLState: 42883
 
  Tentei contornar o problema criando os operadores:
  CREATE OPERATOR = (PROCEDURE = fn_int8eqvarchar, LEFTARG = int8 ,
 RIGHTARG =
  varchar)
  CREATE OPERATOR = (PROCEDURE = fn_varchareqint8, LEFTARG = varchar ,
 RIGHTARG =
  int8)
 
  Mas tive um efeito colateral inadmissível. Comparações varchar =
 varchar
  passaram a dar erro:
  Error: ERRO: sintaxe de entrada é inválida para integer: P
  SQLState: 22P02
 
  Alguma sugestão?
  Conserte sua aplicação. Ela é que está errada, não o banco de dados.
  Isso já foi discutido aqui e nos fóruns internacionais. Os
  desenvolvedores avisaram sobre isso nos release notes.
  A conversão automática de tipos foi removida a partir do PostgreSQL
  8.3, ou seja, já faz tempinho.
 
  []s
  Flavio Gurgel
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
  Não tenho essa opção, e se for a única, vou ter que apelar para um
 downgrade.
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  Não é possível a conversão da coluna organizacional.funcionario.matricula
 de varchar para integer? Pelo que pude perceber da sua consulta só tem
 valores numéricos neste campo.
  Um abraço,
  Marçal de Lima hokama--mhok...@hotmail.com
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 Não, o mesmo maldito sistema faz consultas nesse campo com like.
 ___
 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
http://rednaxel.com
___
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 evitar autenticação trust?

2011-03-01 Por tôpico Alexsander Rosa

Há dois motivos para precisar disso:
- sigilo (proteção dos dados contra acesso indevido) e
- licenciamento (proteção do schema contra cópias indevidas)

A criptografia só protege contra o primeiro caso. Nada impede que um
administrador interessado em fazer cópias ilegais faça um DUMP do banco, com
dados criptografados ou não, e instale em outro servidor.

Em 28 de fevereiro de 2011 12:34, Marcelo Silva (IG)
marc...@ig.com.brescreveu:

 Pense o seguinte... a segurança do banco depende da segurança do servidor,
 desta forma presume-se que se o cara tem acesso root ao servidor ele tem
 acesso ao que está nele.
 Existem algumas medidas drasticas a se tomar levando em conta a
 viabilidade,
 por exemplo, se não quer que acessem os arquivos de configurações do
 postgres terá que limitar o acesso as pastas somente ao usuario do
 postgres,
 essa configuração é dor de cabeça, pois as vezes o root precisa ter acesso
 a
 estas pastas pra no caso de ter que reinstalar o postgres e etc... então
 acaba não sendo viavel...
 Agora se o problema é alguém poder ler ou pegar os dados da tua base, você
 poderia gravar tudo encriptado, também não sei se seria o caso... mas são
 coisas a se pensar.

 Se a pessoa tem acesso direto a sua maquina... dificilmente irá conseguir
 bloquear os acessos a base... pois pra cada meio de segurança existem N
 meios de quebrar a segurança quando se tem acesso fisico a maquina.

 Acho que encriptar ainda é a medida mais aconselhavel quando não quer que
 alguem leia o que está ali. (claro que os fontes da aplicação que encripta
 deve estar muito bem guardado e longe do servidor) (acaba virando uma
 neorose rsrs )


 Marcelo Silva
 ---



 -Mensagem Original-
 From: Leandro Guimarães Faria Corcete DUTRA
 Sent: Monday, February 28, 2011 12:01 PM
 To: pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] Como evitar autenticação trust?

 On 2011.F.28 11h45, Fa wrote:
 
  Como proteger um banco de dados Postgres contra acesso indevido, sendo
 que
  basta qualquer um alterar
  o arquivo de configuração pg_hba.conf colocando o modo de autenticação
  trust no servidor
  para conseguir acesso total ao servidor Postgres inclusive como
  super-usuário sem informar senha alguma?

 O pg_hba.conf somente pode ser editado pelo administrador, portanto não
 há problema algum.







 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Nomes das colunas na tablefunc

2011-02-10 Por tôpico Alexsander Rosa

http://www.postgresql.org/docs/current/static/tablefunc.html

select * from crosstab(
 'select year, month, qty from sales order by 1',
 'select m from generate_series(1,12) m'
 ) as (
 year int,
 Jan int,
 Feb int,
 Mar int,
 Apr int,
 May int,
 Jun int,
 Jul int,
 Aug int,
 Sep int,
 Oct int,
 Nov int,
 Dec int
 );

Eu gostaria de algo assim:

select * from alguma_funcao(
  'select year, month, qty from sales order by 1',
  'select m from generate_series(1,12) m',
  'select nome_mes from calendario order by 1');

Isso existe?

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

Re: [pgbr-geral] Nomes das colunas na tablefunc

2011-02-10 Por tôpico Alexsander Rosa

Mas ali embaixo, depois do AS, estão listados os nomes dos meses.
Eu gostaria de poder puxar estes rótulos do banco de dados.

2011/2/10 Fabrízio de Royes Mello fabriziome...@gmail.com



 2011/2/10 Alexsander Rosa alexsander.r...@gmail.com

 Eu gostaria de algo assim:

 select * from alguma_funcao(
   'select year, month, qty from sales order by 1',
   'select m from generate_series(1,12) m',

   'select nome_mes from calendario order by 1');

 Isso existe?



 Alexander,

 Veja se isso ajuda:


 http://www.postgresonline.com/journal/archives/14-CrossTab-Queries-in-PostgreSQL-using-tablefunc-contrib.html

 Foi o meu primeiro (e único) contato com essa contrib... usei ela para
 listar os salários pagos por mês de cada funcionário na folha de
 pagamento... a query que utilizei é a que segue:

 SELECT relatorio.*
   FROM crosstab($$
   select cast(to_char(r14_regist, '00') || '-' || z01_nome as text) as
 row_name,
  cast(to_char(date '2010-01-01' + ((r14_mesusu-1)||'
 month')::interval, 'mon') as text) as bucket,
  cast(round(sum(r14_valor),2) as integer) as bucketvalue
 from gerfsal
  inner join rhpessoal on rh01_regist = r14_regist
  inner join cgm   on z01_numcgm  = rh01_numcgm
where r14_anousu = 2010
  and r14_pd = 1
 group by r14_anousu,
  r14_mesusu,
  r14_regist,
  z01_nome
 order by 1, r14_mesusu $$,
$$SELECT to_char(date '2010-01-01' + (n || '
 month')::interval, 'mon') As short_mname
   FROM generate_series(0,11) n$$) AS relatorio(item_name
 text,
   jan integer,
   feb integer,
   mar integer,
   apr integer,
   may integer,
   jun integer,
   jul integer,
   aug integer,
   sep integer,
   oct integer,
   nov integer,
   dec integer);

 Essa query vai listar a Matricula e Nome do Funcionário e o valor bruto do
 salário mês a mês do ano de 2010.

 Não sei se ajudei muito, mas aquele artigo me ajudou bastante a construir
 essa query.

 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello


 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] sql formatar nome

2011-02-09 Por tôpico Alexsander Rosa

E o Marcelo Tas ficaria com sobrenome em minúsculas também.
Acho melhor ter a lista com todas as palavras que, isoladas, ficam
minúsculas.

Em 7 de fevereiro de 2011 20:06, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 Em 7 de fevereiro de 2011 18:09, Leonardo Cezar lhce...@gmail.comescreveu:


 Com um pouquinho mais de criatividade e tempo dá pra resolver melhor,
 mas é por aqui:

 SELECT regexp_replace(initcap('leonardo danubio henrique da silva dos
 santos cezar'), '([[:upper:]])(a|as|os)[[:blank:]]', E'd\\2 ', 'g');

   regexp_replace
 -
  Leonardo Danubio Henrique da Silva dos Santos Cezar
 (1 row)



 Só um ajuste para o caso de existir a preposição de:

 postgres@bdteste=# SELECT regexp_replace(initcap('fabrizio de royes
 mello'), '([[:upper:]])(a|as|os|e)[[:blank:]]', E'd\\2 ', 'g');
  regexp_replace
 -
  Fabrizio de Royes Mello
 (1 row)


 Ainda tens de incrementar um pouco essa expressão regular, pois pode
 existir um nome do tipo:

 fulano de tal souza e silva

 Usando a expressão acima fica:

 postgres@bdteste=# SELECT regexp_replace(initcap('fulano de tal souza e
 silva'), '([[:upper:]])(a|as|os|e)[[:blank:]]', E'd\\2 ', 'g');
 regexp_replace
 -
  Fulano de Tal Souza E Silva
 (1 row)


 Mas isso fica para tema de casa...

 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello


 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Escape tratamento

2011-02-08 Por tôpico Alexsander Rosa

Não seria E'130\\' com duas contra-barras?

Em 8 de fevereiro de 2011 16:47, Tiago Valério
tiagosvale...@gmail.comescreveu:

 Pessoal

 Uma ajuda na sintax abaixo :

 INSERT INTO ende(logradouro,numero,complemento)
 SELECT E'130\'

 O '\' mesmo colocando o E na frente para tratamento de escape ele me
 retorna um erro.Existira algum parametro de sessao que eu possa alterar para
 contornar este erro?Sei colocando outra barra o problema é resolvido.


 Grato desde ja.


 ___
 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
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Autenticação com senha obrigatória

2011-01-25 Por tôpico Alexsander Rosa

Não tem como impedir que um usuário root acesse uma base PostgreSQL --
como o Euler disse, ele tem várias opções. Se desse pra criar um usuário
suporte com poderes quase iguais ao do root mas sem acesso aos dados do
PostgreSQL, já serviria. Também vejo este conflito acontecer em clientes,
especialmente quando há mais de uma empresa fornecendo serviços que rodam
num mesmo servidor. Não é uma situação ideal mas no mundo real ela é bem
corriqueira.

Em 25 de janeiro de 2011 08:17, Edson neto edson.edsn...@gmail.comescreveu:

 Obrigado pela ajuda pessoal,
 Realmente seria muito interessante se essa funcionalidade existisse em
 tempo de instalação.
 Mas concordo com o Euler que é falha de segurança do SO.
 Porém quando instalamos o software em um cliente não é possível dizer ao
 mesmo que ele não terá a senha de root do próprio servidor que nos
 disponibilizou. Por isso não há como saber quantas pessoas terão acesso a
 essa maquina.
 Somente a solicitação obrigatória da senha poderia garantir uma segurança
 extra aos dados.

 Obrigado,
 Edson Souza


 Em 24 de janeiro de 2011 19:37, Euler Taveira de Oliveira 
 eu...@timbira.com escreveu:

 Em 24-01-2011 17:49, Avelino Brun escreveu:
  Pode nos dizer quais as formas. Interessante seria uma em que não
 precise
  alterar os fontes.
 Para que? Se eu tenho acesso super-usuário (root) ao servidor PostgreSQL,
 (i)
 basta compilar um outro PostgreSQL e iniciar o novo binário apontando para
 o
 $PGDATA ou (ii) copiar o $PGDATA para uma outra máquina da mesma
 arquitetura/SO.

 Caso o acesso ao $PGDATA seja restrito ao super-usuário e ao usuário
 postgres,
 nenhum outro usuário (não autorizado) poderá usar tais artifícios para
 acessar
 os seus dados indevidamente. Como eu já disse: o seu problema é de
 *segurança
 do SO* e não do PostgreSQL em si.

  Se fosse passando parametros durante a instalação creio que facilitaria.
 
 não espere que a equipe de desenvolvimento vá aceitar tal patch; é um
 problema
 de segurança do SO.


 --
   Euler Taveira de Oliveira
   http://www.timbira.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] Procurar determinada função pela sua DDL

2010-09-13 Por tôpico Alexsander Rosa

Procura na pg_proc, acho que lá tem o tipo de retorno.
Ex: select * from pg_proc where proname = 'sp_retorno';

Em 13 de setembro de 2010 18:00, Thiago zan...@farmaponte.com.br escreveu:

 Por exemplo, tenho uma função que tem o seguinte código:

 declare
vint integer;
 begin
vint := 10;
return vint;
 end;

 Mas preciso procurar na DLL dela que tem o seguinte código:

 CREATE OR REPLACE FUNCTION schema.sp_retorno () RETURNS integer AS
 $body$
 declare
vint integer;
 begin
vint := 10;
return vint;
 end;
 $body$
 LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;

 Procurando na tabela pg_proc procuro apenas da primeira forma, mas se
 precisar por exemplo listar todas as procedures que retornem um
 determinado tipo, por exemplo:

 RETURNS schema.tp_retorno

 Isso que não consigo fazer.

 Obrigado.


-- 
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 Mudar a Posição dos Campos ?

2010-09-06 Por tôpico Alexsander Rosa

Você precisa MESMO disto? O ideal é usar os nomes das colunas nos comandos
SQL.

Em 6 de setembro de 2010 17:40, Marcelo Silva marc...@ig.com.br escreveu:

  Pessoal, como faz pra mudar a posição de um campo?
 Procurei no pgAdmin3 mas não achei
 O Postgres aceita isso ?

 Exemplo, tenho a tabela

 Funcionarios

 cod_fun
 nome
 rg
 cod_emp
 cpf

 Queria mudar para

 cod_fun
 nome
 cpf
 rg
 cod_emp


 Mas sem ter que deletar e recriar os campos denovo pois a tabela já está
 populada.




-- 
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] Somar horas tendo somente uma coluna

2010-09-01 Por tôpico Alexsander Rosa

Poderia ser uma diferença entre um max() e um min() numa subquery.

Em 1 de setembro de 2010 15:41, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 Em 1 de setembro de 2010 15:31, Victor Hugo vh.cleme...@gmail.comescreveu:


 Vc quer diminuir usando função de agregação SUM ??? SUM é para somar...

 é isso mesmo ??? Se não for, resolva com a query abaixo

 SELECT SUM(EXTRACT (minutes from data_sessao))
 FROM horas where id_usuario = 4

 aí no caso ele irá extrair os minutos do primeiro valor que é 15 + do
 segundo valor que é 17 contabilizando um total de 32 minutos.


 Exato... só exemplificando o que pode acontecer:

 postg...@bdteste=# create table sessao (id serial, data_sessao timestamp,
 id_usuario integer);
 NOTICE:  CREATE TABLE will create implicit sequence sessao_id_seq for
 serial column sessao.id
 CREATE TABLE
 postg...@bdteste=# insert into sessao (data_sessao, id_usuario) values
 ('2010-09-01 14:15:00.00', 4), ('2010-09-01 14:17:00.00', 4);INSERT
 0 2
 postg...@bdteste=# insert into sessao (data_sessao, id_usuario) values
 ('2010-09-02 13:10:00.00', 4), ('2010-09-02 13:18:00.00', 4);
 INSERT 0 2
 postg...@bdteste=# select max(data_sessao) - min(data_sessao) from sessao;
  ?column?
 --
  23:03:00
 (1 row)


 Nesse caso foi verificado o intervalo de tempo entre a menor e maior
 data/hora, mas creio que isso não seja o desejado, então quem sabe:

 postg...@bdteste=# select data_sessao::date, max(data_sessao) -
 min(data_sessao) from sessao group by 1;
  data_sessao | ?column?
 -+--
  2010-09-02  | 00:08:00
  2010-09-01  | 00:02:00
 (2 rows)


 Ou ainda:

 postg...@bdteste=# select sum(intervalo) from (select data_sessao::date,
 max(data_sessao) - min(data_sessao) as intervalo from sessao group by 1) as
 tempo;
sum
 --
  00:10:00
 (1 row)


 Dai depende dos teus requisitos!

 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.com
  Perfil Linkedin: http://br.linkedin.com/in/fabriziomello


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

2010-08-31 Por tôpico Alexsander Rosa

Só eu achei que isto é um bug -- e perigoso?

- Se você der um ALTER SEQUENCE ... START N num servidor 8.4 o valor da
sequence NÃO é alterado. Este comando apenas altera o valor inicial para o
qual a sequence será resetada se for dado um RESTART sem parâmetros.

- Se você der um ALTER SEQUENCE ... START N num servidor 8.x (com x  4), o
valor é ALTERADO !!! Por um erro de implementação, o servidor vai executar
um RESTART, resetando a sequence para o valor informado. Esta cláusula não
existe nas versões 8.x antes da 8.4, mas ao invés do comando dar um ERRO ele
executa OUTRO comando!!!

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

 Comentário do Tom Lane sobre o problema:
 http://archives.postgresql.org/pgsql-bugs/2010-08/msg00349.php


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

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

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



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

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


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

 Testei num 8.3.9 e funcionou normalmente

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


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

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

 # alter SEQUENCE teste_id_seq start 2000;
 ALTER SEQUENCE

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

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


 # alter SEQUENCE teste_id_seq restart 1;
 ALTER SEQUENCE

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

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

 --
 Marcelo Costa


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

Explicando em mais detalhes:

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

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

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

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

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

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

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

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



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

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


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

 Testei num 8.3.9 e funcionou normalmente

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


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

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

 # alter SEQUENCE teste_id_seq start 2000;
 ALTER SEQUENCE

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

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


 # alter SEQUENCE teste_id_seq restart 1;
 ALTER SEQUENCE

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

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

 --
 Marcelo Costa


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

Re: [pgbr-geral] Como usar o pgcrypto

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

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

 Olá,

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

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


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

 Exemplo:

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



 Grato
 Beto Lima

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



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

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

Comentário do Tom Lane sobre o problema:
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00349.php

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

2010-08-26 Por tôpico Alexsander Rosa

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

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

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

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

2010-08-26 Por tôpico Alexsander Rosa

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

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

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

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

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

 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

2010-08-25 Por tôpico Alexsander Rosa

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

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

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

--
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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] RES: RES: RES: Lentidão em se rvidor de dados

2010-08-25 Por tôpico Alexsander Rosa

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

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

  No *dmesg* achei estranho a seguinte mensagem:



 *temperature above threshold. cpu clock throttled*



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

 Não sei dizer se isso é normal acontecer.



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



 Marlon,

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

 Abraços,
 Aldrey Galindo





-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

Re: [pgbr-geral] Dá para armazenar arquivos XML?

2010-08-23 Por tôpico Alexsander Rosa

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

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

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


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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

Re: [pgbr-geral] Consulta lenta

2010-07-28 Por tôpico Alexsander Rosa

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

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

  Olá!



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



 select count(*) from history;



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



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

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

 Faço analyze e reindexação semanalmente.



 Estou utilizando postgresql 8.4.4



 A tabela tem a seguinte estrutura e índice:



 CREATE TABLE history

 (

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

   clock integer NOT NULL DEFAULT 0,

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

 )

 WITH (OIDS=TRUE);



 -- Index: history_1



 CREATE INDEX history_1  ON.history

   USING btree  (itemid, clock);





 *Mônica***





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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

2010-07-26 Por tôpico Alexsander Rosa

Tem certeza que a modelagem está correta?

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

 Bom dia!

 Estou precisando de uma ajuda no seguinte:

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

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

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

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

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

 Preciso executar o seguinte SQL:

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

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

 Alguem tem ideia de como fazer isso?



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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

Re: [pgbr-geral] Delete *

2010-07-22 Por tôpico Alexsander Rosa

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

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

 Olá,

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

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

 BEGIN e COMMIT/SAVEPOINT/ROLLBACK

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


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

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

 CREATE OR REPLACE FUNCTION exclusao(INTEGER)

 RETURNS BOOLEAN AS $$

 BEGIN

 DELETE FROM tabela WHERE campo_chave=$1;

 IF FOUND THEN

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

 RETURN TRUE;

 END IF;

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

 RETURN FALSE;

 END;

 $$ LANGUAGE PLPGSQL RETURNS NULL ON NULL INPUT;


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



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

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

2010-07-09 Por tôpico Alexsander Rosa

Vamos por partes.

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

 Treços do teu email:

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


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



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


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


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


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


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

 Elegância é subjetiva.


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

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



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

 Abraço,
 Fabiano Machado Dias


 Agradeço seus comentários.



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


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

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

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

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

 Bom dia pessoal,

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

 --
 Lucas Lima

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

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

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

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

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

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

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

 Att,
 Fabiano Machado Dias

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


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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

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

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

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

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





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

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

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

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

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

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

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

 Att,
 Fabiano Machado Dias


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

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

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