[pgbr-geral] Como integro o PostgreSQL ao openoffice?

[Leonardo Vilar]

como integro o banco de dados ao openoffice?

--
--

Atenciosamente

Leonardo Vilar Tavares da Silva

__
Faça ligações para outros computadores com o novo Yahoo! Messenger 
http://br.beta.messenger.yahoo.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 com Indice Composto

[Joao]

a presença de nulls na maioria das vezes  significa modelagem mal feita
- Original Message - 
From: "Leandro DUTRA" <[EMAIL PROTECTED]>
To: "Comunidade PostgreSQL Brasileira" 
Sent: Monday, June 02, 2008 5:29 PM
Subject: Re: [pgbr-geral] Ajuda com Indice Composto


2008/6/2 Vi <[EMAIL PROTECTED]>:
> Vou tentar resolver isso sem usar indice.

Ou talvez normalizar para evitar tantos NULLs?

Ficou meio confusa a seqüência de informações, mas um bom modelo
poderia ajudar em lugares insuspeitos.

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

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

[pgbr-geral] instalacao CEDRUS

[Ni]

Alguem sabe como faco p/ instalar o CEDUS?

-- 
View this message in context: 
http://www.nabble.com/instalacao-CEDRUS-tp17581269p17581269.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

[pgbr-geral] Falha no schema com o SLONY

[Ni]

OI Pessoal,

Alguem pode me ajudar? eu instalei o slony e como nao sei muito, estou
seguindo um tutorial, mas o problema 'e que quando rodo um script p/ troca
de SYNCS entre os nodos, ocorre o seguinte erro: ERROR:  schema "_teste"
does not exist
BRT ERROR  cannot get sl_local_node_id - ERROR:  schema "_teste" does not
exist
Mas o esquema existe dentro das duas bases, master e slave.

Algu'em tem alguma sugestao?
-- 
View this message in context: 
http://www.nabble.com/Falha-no-schema-com-o-SLONY-tp17579080p17579080.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Bruno Simioni]

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
> > Só acho válido uma discussão sobre a cardinalidade, a qual você se
> refereriu
> > como engenharia reversa.
>
> Não, não foi esse o termo.
>
> Aliás, por favor corte o que for desnecessário para responder, está
> complicado responder a esta lista.
>
>
> > Cadinalidades de 1 para 1, trabalhariam dessa forma, e não afetariam a
> > normalização do banco.
>
> Exemplos?
>
>
Quanto ao excesso do texto, me desculpe. Estava usando o "reply" sem
perceber o problema.

Tente no exemplo:

Dado duas relações, eventos e visitas. Para que haja um evento, é necessária
uma única visita. Não poderá ocorrer mais do que uma visita para cada
evento.

Nesse caso, posso ter a chave primária de visita em eventos, bem como, a
chave primária do evento na visita, que mantenho normalizado.

Que acha?

Abraços,

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
> Só acho válido uma discussão sobre a cardinalidade, a qual você se refereriu
> como engenharia reversa.

Não, não foi esse o termo.

Aliás, por favor corte o que for desnecessário para responder, está
complicado responder a esta lista.


> Cadinalidades de 1 para 1, trabalhariam dessa forma, e não afetariam a
> normalização do banco.

Exemplos?

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Bruno Simioni]

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
> >
> > O que seria "normalização reversa" ?
>
> Encontrei numa aplicação uma vez, numa montadora.  A tabela pai
> continha as chaves das filhas, em vez das filhas se referirem à pai...
>
> No caso eram laudos técnicos, aos quais associavam-se eventos como
> revisões, aprovações &c.  Em vez dessas tabelas auxiliares conterem a
> chave do laudo a que se referiam, era a tabela de laudos que tinha a
> chave de revisão, de aprovação, &c... e assim só podia relacionar-se
> ao último evento de cada tipo!
>
> Não que o modelo da Apple seja assim; só para exemplificar como me dei
> mal com essa notação da Apple.
>
>
> > Quanto ao Postgres, provavelmente além do Bonjour, todas essas coisas
> devem
> > estar agregadas ao elefante :)
>
> Seria interessante saber exatamente como o PostgreSQL é usado no Mac OS.
>
>
> > Dê uma olhada mais especificamente em:
> >
> http://developer.apple.com/documentation/AppleApplications/Reference/SyncServicesSchemaRef/Articles/Contacts.html
>
> Pois é, mas foi daí mesmo que veio minha confusão.
>
> Supondo que realmente tenha sido só mal-entendido meu, pareceria um bom
> modelo.
>
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Entendido, Leandro,

Só acho válido uma discussão sobre a cardinalidade, a qual você se refereriu
como engenharia reversa.

Concordo que há casos em que ter a chave do item referenciado no pai, ao
invés do inverso, é um tanto quanto pecaminoso. Poderia até gerar uma
relação desnecessária no banco de dados, se o raciocínio de cardinalidade N
para N fosse colocado de maneira confusa. Porém, há casos, em que, devido ao
problema, deva ser assim, não acha?

Cadinalidades de 1 para 1, trabalhariam dessa forma, e não afetariam a
normalização do banco.

O que acha? tanto faz, nesse caso?

Abraços,

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
>
> O que seria "normalização reversa" ?

Encontrei numa aplicação uma vez, numa montadora.  A tabela pai
continha as chaves das filhas, em vez das filhas se referirem à pai...

No caso eram laudos técnicos, aos quais associavam-se eventos como
revisões, aprovações &c.  Em vez dessas tabelas auxiliares conterem a
chave do laudo a que se referiam, era a tabela de laudos que tinha a
chave de revisão, de aprovação, &c... e assim só podia relacionar-se
ao último evento de cada tipo!

Não que o modelo da Apple seja assim; só para exemplificar como me dei
mal com essa notação da Apple.


> Quanto ao Postgres, provavelmente além do Bonjour, todas essas coisas devem
> estar agregadas ao elefante :)

Seria interessante saber exatamente como o PostgreSQL é usado no Mac OS.


> Dê uma olhada mais especificamente em:
> http://developer.apple.com/documentation/AppleApplications/Reference/SyncServicesSchemaRef/Articles/Contacts.html

Pois é, mas foi daí mesmo que veio minha confusão.

Supondo que realmente tenha sido só mal-entendido meu, pareceria um bom modelo.


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

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
>
> 2008/6/2 Leonardo Cezar <[EMAIL PROTECTED]>:
>>
>> Quem deve conter (restringir) dados em sua aplicação é o repositório e
>> não a interface.
>
> Levando em consideração que repositório seria o SGBD, não concordo em deixar
> a base de dados restringir os dados da aplicação.

Pelo contrário!


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

Re: [pgbr-geral] Ajuda com Indice Composto

[Leandro DUTRA]

2008/6/3 Leonardo Vilar <[EMAIL PROTECTED]>:
> Leandro DUTRA wrote:
>> Por favor, evite escrever no topo, siga a prática da lista e o RFC 1855.
>
> eu uso o thunderbird como leitor de e-mail.

É a forma, não a ferramenta.

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

Re: [pgbr-geral] Ajuda com Indice Composto

[Leonardo Vilar]

Leandro DUTRA wrote:

2008/6/2 Vi <[EMAIL PROTECTED]>:
  

Bom esse eh o explain;



Por favor, evite escrever no topo, siga a prática da lista e o RFC 1855.

Ainda precisamos do resto das informações pedidas.

Estou vendo Index Scan, qual o problema?  Sem saber o que são esses
índices e o resto da estrutura, fica difícil.

  

eu uso o thunderbird como leitor de e-mail.

--
--

Atenciosamente

Leonardo Vilar Tavares da Silva



___ 
Yahoo! Mail - Sempre a melhor opção para você! 
Experimente já e veja as novidades. 
http://br.yahoo.com/mailbeta/tudonovo/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] qual o melhor grupo

[Thiago Tiedtke]

Opa, blz!

Não entendi muito o que você quis dizer com grupo, mas vamos lá...

Já que vai trabalhar em latitude e longitude, seria mais interessante vc
convertê-las para graus decimais, e gravar em um campo double.

Mas para o postgreSQL existe a extensão para armazenar e fazer manipução de
dados geográficos, chamada PostGIS[1], mas isso quando vc pretentede fazer
cargas de feições para trabalhar com servidores de mapas, por exemplo o
mapserver[2], além de inumeras operações de consultas de proximidade,
buffer, etc..

Mais ou menos isso?

[1] http://www.postgis.org/
[2] http://mapserver.gis.umn.edu/

[]s

Thiago Tiedtke dos Reis

2008/6/2 Leonardo Vilar <[EMAIL PROTECTED]>:

> Estou estudando comandos sql e comecei a estudar o postgresql e gostaria de
> saber qual grupo eu posso usar dados do tipo numeros e caracteres para eu
> poder inserir na tabela tempo, por exemplo, a latitude e longitude de Belém:
> "01º 27' S", "48º 30' O".*
> <
> http://tools.wikimedia.de/%7Emagnus/geo/geohack.php?pagename=Bel%C3%A9m&language=pt¶ms=01_27_21_S_48_30_14_W_
> >*
>
> --
> --
>
> Atenciosamente
>
> Leonardo Vilar Tavares da Silva
>
>
>
>
>
>
> ___ Yahoo! Mail -
> Sempre a melhor op�ão para você! Experimente já e veja as novidades.
> http://br.yahoo.com/mailbeta/tudonovo/
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] qual o melhor grupo

[Leonardo Vilar]

Estou estudando comandos sql e comecei a estudar o postgresql e gostaria 
de saber qual grupo eu posso usar dados do tipo numeros e caracteres 
para eu poder inserir na tabela tempo, por exemplo, a latitude e 
longitude de Belém: "01º 27' S", "48º 30' O".*

*

--
--

Atenciosamente

Leonardo Vilar Tavares da Silva






___ 
Yahoo! Mail - Sempre a melhor opção para você! 
Experimente já e veja as novidades. 
http://br.yahoo.com/mailbeta/tudonovo/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Bruno Simioni]

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
> >
> > Você pode começar consultando a referência do portal de desenvolvimento
> da
> > Apple.
> >
> >
> http://developer.apple.com/reference/AppleApplications/idxAddressBook-date.html
>
> Interessante, mas não entendi a notação que usaram para descrever o
> esquema.  Dá impressão duma 'normalização reversa', mas creio que eu
> não esteja entendendo mesmo.
>
> Será que tem algo similar em SQL?
>
> Me faz lembrar que o Rendezvous usa PostgreSQL embutido no Mac OS X,
> que eu me lembre... será que essas bases também?
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Dutra,

O que seria "normalização reversa" ?

Quanto ao Postgres, provavelmente além do Bonjour, todas essas coisas devem
estar agregadas ao elefante :)

Dê uma olhada mais especificamente em:
http://developer.apple.com/documentation/AppleApplications/Reference/SyncServicesSchemaRef/Articles/Contacts.html

Creio que essa modelagem resolva o fato de não estar em SQL.

Abraços.

-- 
---
Bruno Simioni
---
Caiena - Soluções em Gestão do Conhecimento
Rua 11, n.2627 Sala 13 - Santana - Rio Claro/SP
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Bruno Simioni]

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 Aldemir Vieira <[EMAIL PROTECTED]>:
> > Outra fonte de modelos prontos:
> >
> > http://www.databaseanswers.org/data_models/index.htm
> >
> > O link 102 .Contacts and Products traz a idéia que contatos tem meios de
> > comunicação.
>
> Seria
> http://www.databaseanswers.org/data_models/contact_management/index.htm,
> mas não é um bom modelo.
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Realmente, não é um bom modelo.

Há confusão sobre o que é informação pessoal, informação profissional, e
outras categorias de informações sobre o mesmo contato.

Creio que modelagem satisfatória cuidaria em separar, de uma forma que
garanta escalabilidade às propriedades de um contato, todas as categorias de
informações sobre  uma determinada entidade, que no caso, dá-se por
contatos.

-- 
---
Bruno Simioni
---
Caiena - Soluções em Gestão do Conhecimento
Rua 11, n.2627 Sala 13 - Santana - Rio Claro/SP
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Bruno Simioni]

2008/6/2 Leonardo Cezar <[EMAIL PROTECTED]>:

> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
>
> > Será se é necessário este detalhamento -> CHECK (des_contato_pessoa ~
> > '^[a-z]{3,[EMAIL PROTECTED],}$'); Ou poderia colocar um campo na tabela tipo
> contato
> > com descricao_mascara, sendo uma expressao regular e deixar a aplicação
> usar
> > este campo para validar se grava ou nao na tabela pessoa contato?
>
> Quem deve conter (restringir) dados em sua aplicação é o repositório e
> não a interface.
>
> Confesso que classificaria isto como uma anomalia.
>
> -Leo
> --
> Leonardo Cezar
> http://pgcon.postgresql.org.br
> http://www.dextra.com.br/postgres
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Levando em consideração que repositório seria o SGBD, não concordo em deixar
a base de dados restringir os dados da aplicação.

Creio que seria mais viável deixar às nescessidades do projeto, apresentar
ou não informações que interessem. Isso também vai da forma com que se
aborda o problema, e da caracterização da base de dados.

Você pode, dessa forma, garantir escalabilidade do sistema como um todo.

-- 
---
Bruno Simioni
---
Caiena - Soluções em Gestão do Conhecimento
Rua 11, n.2627 Sala 13 - Santana - Rio Claro/SP
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Leonardo Cezar]

2008/6/2 junior Prado <[EMAIL PROTECTED]>:

> Será se é necessário este detalhamento -> CHECK (des_contato_pessoa ~
> '^[a-z]{3,[EMAIL PROTECTED],}$'); Ou poderia colocar um campo na tabela tipo 
> contato
> com descricao_mascara, sendo uma expressao regular e deixar a aplicação usar
> este campo para validar se grava ou nao na tabela pessoa contato?

Quem deve conter (restringir) dados em sua aplicação é o repositório e
não a interface.

Confesso que classificaria isto como uma anomalia.

-Leo
-- 
Leonardo Cezar
http://pgcon.postgresql.org.br
http://www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[junior Prado]

Leandro,

pelo que entendi no diagrama de classes o Contact implementa uma fabrica
abstrata...

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
> >
> > Você pode começar consultando a referência do portal de desenvolvimento
> da
> > Apple.
> >
> >
> http://developer.apple.com/reference/AppleApplications/idxAddressBook-date.html
>
> Interessante, mas não entendi a notação que usaram para descrever o
> esquema.  Dá impressão duma 'normalização reversa', mas creio que eu
> não esteja entendendo mesmo.
>
> Será que tem algo similar em SQL?
>
> Me faz lembrar que o Rendezvous usa PostgreSQL embutido no Mac OS X,
> que eu me lembre... será que essas bases também?
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
VALTER CEZAR PRADO JUNIOR
GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
ANALISTA DE SISTEMAS - BYSAT
DBA / PROJETISTA DE SISTEMAS - PBH

Sem saber como fazer ele fez!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 Aldemir Vieira <[EMAIL PROTECTED]>:
> Outra fonte de modelos prontos:
>
> http://www.databaseanswers.org/data_models/index.htm
>
> O link 102 .Contacts and Products traz a idéia que contatos tem meios de
> comunicação.

Seria http://www.databaseanswers.org/data_models/contact_management/index.htm,
mas não é um bom modelo.

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

Re: [pgbr-geral] Ajuda com Indice Composto

[Leandro DUTRA]

2008/6/2 Vi <[EMAIL PROTECTED]>:
> Vou tentar resolver isso sem usar indice.

Ou talvez normalizar para evitar tantos NULLs?

Ficou meio confusa a seqüência de informações, mas um bom modelo
poderia ajudar em lugares insuspeitos.

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Aldemir Vieira]

Outra fonte de modelos prontos:

http://www.databaseanswers.org/data_models/index.htm

O link 102 .Contacts and
Productstraz
a idéia que contatos tem meios de comunicação.


2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:

> Olá Junior,
>
> Sua modelagem me pareceu um tanto confusa, por ter misturado conceitos que
> formam o tipo do contato, com o contato em si, em relaçao ao que seria um
> atributo do contato.
>
> Você pode se orientar melhor com a modelagem de contatos, seguindo os
> padrões já estabelecidos, e afirmados.
>
> Você pode começar consultando a referência do portal de desenvolvimento da
> Apple.
>
>
> http://developer.apple.com/reference/AppleApplications/idxAddressBook-date.html
>
> Abraços,
>
> -
> ---
> Bruno Simioni
> ---
> Caiena - Soluções em Gestão do Conhecimento
> Rua 11, n.2627 Sala 13 - Santana - Rio Claro/SP
>
>
> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
>
>> Galera,
>>
>>
>> Pensando em contatos de pessoas, procurando normalizar criei a seguinte
>> estrutura:
>>
>> TIPO CONTATO
>> Idnome_contato
>> 1  telefone
>> 2  e-mail
>>
>> PESSOA
>> Id nome_pessoa
>> 1   Zé
>> 2   João
>>
>> PESSOA CONTATO
>> id  id_pessoa  id_contato  des_contato_pessoa
>> 1   11 9874-4561
>> 2   21 4567-6541
>> 3   12 [EMAIL PROTECTED]
>>
>> Perguntas:
>>
>> É a melhor forma de normalizar?
>> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
>> telefone E - e-mail) eliminando a tabela tipo de contato, com isto ganharia
>> desempenho?
>> Sugestões, dicas, artigos?
>> Quando é melhor fazer um tabelão do que normalizar?
>>
>>
>> --
>> VALTER CEZAR PRADO JUNIOR
>> GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
>> ANALISTA DE SISTEMAS - BYSAT
>> DBA / PROJETISTA DE SISTEMAS - PBH
>>
>> Sem saber como fazer ele fez!
>> ___
>> 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
>
>


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

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 Bruno Simioni <[EMAIL PROTECTED]>:
>
> Você pode começar consultando a referência do portal de desenvolvimento da
> Apple.
>
> http://developer.apple.com/reference/AppleApplications/idxAddressBook-date.html

Interessante, mas não entendi a notação que usaram para descrever o
esquema.  Dá impressão duma 'normalização reversa', mas creio que eu
não esteja entendendo mesmo.

Será que tem algo similar em SQL?

Me faz lembrar que o Rendezvous usa PostgreSQL embutido no Mac OS X,
que eu me lembre... será que essas bases também?

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

Re: [pgbr-geral] Ajuda com Indice Composto

[Vi]

Ok. muito obrigada pela atenção.
Vou tentar resolver isso sem usar indice.
Qto a versao do banco utilizo a 8.2

Em 02/06/08, Thiago Risso <[EMAIL PROTECTED]> escreveu:
>
> > A tabela contém muitos registros, por isso a criação de indice.
> > Estou usando indice composto (para a linha grifada em resposta anterior).
> > Passar a estrutura da tabela, fica complicado.
> > A consulta eh a seguinte:
> > SELECT count(distinct(rdelrde)), count(tid), sum(tvlr)
> > FROM titulo, rdel, grrde, grp, csk
> > WHERE
> > (ttctr = rdelctr) and
> > (grpcsk   = cskid ) and
> > (rdelrde = grrderde) and
> > (grrdegrp = grpid) and
> > (cskid = 5) and
> > (tsac = '70064993000140') and
> > (tpgt is null) and
> > (tvct >= '2008-05-14 00:00:00') and
> > (tvct <= '2008-07-14 00:00:00')
> > LIMIT 1;
> > Mas a consulta eh pra retornar informações sobre qtas lojas,  qtos
> titulos
> > e o valor do titulo quando a condicao  for verdadeira.
>
>
> Como já havia escrito na outra mensagem ...
> Se você tiver MUITOS NULLS na tabela ou se o Indice não foi criado
> corretamente, ele não será usado mesmo.
> Normalmente , se 30% dos valores da hash forem NULLS, o planejador não
> usará o indice, pq é mais rápido fazer scan.
> Outra possibilidade é criar indice composto condicional (tsac AND
> ISNULL(tpgt)) e utilizar a funcao na comparação !
>
> Bem .. acho que é isso...
> --
> Att:
>
> Thiago Risso
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Bruno Simioni]

Olá Junior,

Sua modelagem me pareceu um tanto confusa, por ter misturado conceitos que
formam o tipo do contato, com o contato em si, em relaçao ao que seria um
atributo do contato.

Você pode se orientar melhor com a modelagem de contatos, seguindo os
padrões já estabelecidos, e afirmados.

Você pode começar consultando a referência do portal de desenvolvimento da
Apple.

http://developer.apple.com/reference/AppleApplications/idxAddressBook-date.html

Abraços,

-
---
Bruno Simioni
---
Caiena - Soluções em Gestão do Conhecimento
Rua 11, n.2627 Sala 13 - Santana - Rio Claro/SP


2008/6/2 junior Prado <[EMAIL PROTECTED]>:

> Galera,
>
> Pensando em contatos de pessoas, procurando normalizar criei a seguinte
> estrutura:
>
> TIPO CONTATO
> Idnome_contato
> 1  telefone
> 2  e-mail
>
> PESSOA
> Id nome_pessoa
> 1   Zé
> 2   João
>
> PESSOA CONTATO
> id  id_pessoa  id_contato  des_contato_pessoa
> 1   11 9874-4561
> 2   21 4567-6541
> 3   12 [EMAIL PROTECTED]
>
> Perguntas:
>
> É a melhor forma de normalizar?
> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> telefone E - e-mail) eliminando a tabela tipo de contato, com isto ganharia
> desempenho?
> Sugestões, dicas, artigos?
> Quando é melhor fazer um tabelão do que normalizar?
>
>
> --
> VALTER CEZAR PRADO JUNIOR
> GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
> ANALISTA DE SISTEMAS - BYSAT
> DBA / PROJETISTA DE SISTEMAS - PBH
>
> Sem saber como fazer ele fez!
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


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

Re: [pgbr-geral] NORMALIZAÇÃO

[flavio cardoso]

concordo plenamente. a primeira vista até parece trivial, mas quem tem
experiência sabe que não é tão simples assim.

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> > Agradeço a todos pela postagens. E gostaria de deixar bem claro que não
> > estou buscando "consultoria voluntariamente", apenas procuro trocar
> opiniões
> > na lista de discussão. Novamente agradeço a todos pela boa vontade.
>
> Não se ofenda — é que modelagem é realmente difícil de discutir por
> correio eletrônico, é difícil dar opiniões bem fundamentadas porque
> envolve questões muito específicas de sua organização.
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
O temor do Senhor é o princípio do conhecimento; mas os insensatos desprezam
a sabedoria e a instrução. Pv 1;7

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

Re: [pgbr-geral] NORMALIZAÇÃO

[junior Prado]

Leandro,

Obrigado pelo dicas e peço desculpas...
Sei realmente que cada modelagem depende da usabilidade, necessidades e
outras coisas...
Muito obrigado mesmo. Tenha um bom serviço!

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> > Agradeço a todos pela postagens. E gostaria de deixar bem claro que não
> > estou buscando "consultoria voluntariamente", apenas procuro trocar
> opiniões
> > na lista de discussão. Novamente agradeço a todos pela boa vontade.
>
> Não se ofenda — é que modelagem é realmente difícil de discutir por
> correio eletrônico, é difícil dar opiniões bem fundamentadas porque
> envolve questões muito específicas de sua organização.
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
VALTER CEZAR PRADO JUNIOR
GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
ANALISTA DE SISTEMAS - BYSAT
DBA / PROJETISTA DE SISTEMAS - PBH

Sem saber como fazer ele fez!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> Agradeço a todos pela postagens. E gostaria de deixar bem claro que não
> estou buscando "consultoria voluntariamente", apenas procuro trocar opiniões
> na lista de discussão. Novamente agradeço a todos pela boa vontade.

Não se ofenda — é que modelagem é realmente difícil de discutir por
correio eletrônico, é difícil dar opiniões bem fundamentadas porque
envolve questões muito específicas de sua organização.

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

Re: [pgbr-geral] NORMALIZAÇÃO

[junior Prado]

Agradeço a todos pela postagens. E gostaria de deixar bem claro que não
estou buscando "consultoria voluntariamente", apenas procuro trocar opiniões
na lista de discussão. Novamente agradeço a todos pela boa vontade.

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> Nossa, que confusão ficou a mensagem.  Por favor siga a RFC 1855 e a
> prática da lista.
>
>
> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> > 2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:
> > Talvez o que você tenha querido dizer é qual a forma de contato
> > preferida da pessoa?
> >
> > #A lógica é armazenar todos os contatos de uma pessoa, tendo 0..n e-mail
> ou
> > 0..n #telefones
>
> Ah!  Realmente, normalize melhor.  Misturar dois tipos diferentes no
> mesmo atributo, como já apontaram aqui, é sempre roubada.
>
>
>
> > # Para cada pessoa preciso buscar o e-mail e o telefone mais recente caso
> > exista, #me preocupo com joins...
>
> Se se preocupa com junções, evite o uso desses ids quando possível,
> costuma ser muito mais relevante que normalização.
>
> A meu ver bastariam duas tabelas, uma com id_pessoa e o número de
> telefone, outra com id_pessoa e o endereço de correio eletrônico.
>
> Mas de novo, é difícil prestar consultoria voluntariamente e por lista
> de discussão.
>
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
VALTER CEZAR PRADO JUNIOR
GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
ANALISTA DE SISTEMAS - BYSAT
DBA / PROJETISTA DE SISTEMAS - PBH

Sem saber como fazer ele fez!
___
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 com Indice Composto

[Thiago Risso]

> A tabela contém muitos registros, por isso a criação de indice.
> Estou usando indice composto (para a linha grifada em resposta anterior).
> Passar a estrutura da tabela, fica complicado.
> A consulta eh a seguinte:
> SELECT count(distinct(rdelrde)), count(tid), sum(tvlr)
> FROM titulo, rdel, grrde, grp, csk
> WHERE
> (ttctr = rdelctr) and
> (grpcsk   = cskid ) and
> (rdelrde = grrderde) and
> (grrdegrp = grpid) and
> (cskid = 5) and
> (tsac = '70064993000140') and
> (tpgt is null) and
> (tvct >= '2008-05-14 00:00:00') and
> (tvct <= '2008-07-14 00:00:00')
> LIMIT 1;
> Mas a consulta eh pra retornar informações sobre qtas lojas,  qtos titulos
> e o valor do titulo quando a condicao  for verdadeira.

Como já havia escrito na outra mensagem ...
Se você tiver MUITOS NULLS na tabela ou se o Indice não foi criado
corretamente, ele não será usado mesmo.
Normalmente , se 30% dos valores da hash forem NULLS, o planejador não
usará o indice, pq é mais rápido fazer scan.
Outra possibilidade é criar indice composto condicional (tsac AND
ISNULL(tpgt)) e utilizar a funcao na comparação !

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

Re: [pgbr-geral] Ajuda com Indice Composto

[Ribamar Sousa]

Em 02/06/08, Vi<[EMAIL PROTECTED]> escreveu:
> A tabela contém muitos registros, por isso a criação de indice.
> Estou usando indice composto (para a linha grifada em resposta anterior).

Dependendo de quantos campos o índice não será usado.
Não lembro se é a partir de 3 ou de 4 que o PostgreSQL não mais usará o índice.

> Passar a estrutura da tabela, fica complicado.
> A consulta eh a seguinte:
> SELECT count(distinct(rdelrde)), count(tid), sum(tvlr)

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda com Indice Composto

[Thiago Risso]

2008/6/2 Vi <[EMAIL PROTECTED]>:
> Bom esse eh o explain;
> Onde eu preciso que seja usado o indice esta grifado.
>
> Limit  (cost=8.96..8.97 rows=1 width=18)
>->  Aggregate  (cost=8.96..8.97 rows=1 width=18)
>  ->  Nested Loop  (cost=0.00..8.94 rows=1 width=18)
>->  Nested Loop  (cost=0.00..6.66 rows=1 width=22)
>  ->  Nested Loop  (cost=0.00..6.05 rows=1 width=22)
>->  Nested Loop  (cost=0.00..5.77 rows=1
> width=18)
>  ->  Index Scan using idx_tvct on tit
> (cost=0.00..3.49 rows=1 width=18)
>Index Cond: ((tvct = '2008-05-14
> 00:00:00'::timestamp without time zone) AND (tvct <= '2008-07-14
> 00:00:00'::timestamp without time zone))
>Filter: (((tsac)::text =
> '70064993000140'::text) AND (tpgt IS NULL))
>  ->  Index Scan using rdede on rdel
> (cost=0.00..2.27 rows=1 width=8)
>Index Cond: (t.tctr = rdel.rdelctr)
>->  Index Scan using grprrde_grprgrp on grpr
> (cost=0.00..0.27 rows=1 width=8)
>  Index Cond: (rdel.rdelrde = grpr.grprrde)
>  ->  Index Scan using grpgr_pkey on grpgr
> (cost=0.00..0.60 rows=1 width=8)
>Index Cond: (grpgrrde.grpgrrdegrp =
> grpgr.grpgrid)
>Filter: (5 = grpgrcsk)
>->  Index Scan using csk_pkey on csk  (cost=0.00..2.27 rows=1
> width=4)
>  Index Cond: (cskid = 5)


Do manual (v8.2) [1] :
"Indexes are not used for IS NULL clauses by default. The best way to
use indexes in such cases is to create a partial index using an IS
NULL predicate."


[1] http://www.postgresql.org/docs/8.2/static/sql-createindex.html

Qual versão está usando ?!
Qual a % de nulls na coluna para o numero de registros totais ?
Como foi criado o Índice ?!



-- 
Att:
Thiago Risso
___
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 com Indice Composto

[Leandro DUTRA]

2008/6/2 Vi <[EMAIL PROTECTED]>:
> Bom esse eh o explain;

Por favor, evite escrever no topo, siga a prática da lista e o RFC 1855.

Ainda precisamos do resto das informações pedidas.

Estou vendo Index Scan, qual o problema?  Sem saber o que são esses
índices e o resto da estrutura, fica difícil.

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

Nossa, que confusão ficou a mensagem.  Por favor siga a RFC 1855 e a
prática da lista.


2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> 2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:
> Talvez o que você tenha querido dizer é qual a forma de contato
> preferida da pessoa?
>
> #A lógica é armazenar todos os contatos de uma pessoa, tendo 0..n e-mail ou
> 0..n #telefones

Ah!  Realmente, normalize melhor.  Misturar dois tipos diferentes no
mesmo atributo, como já apontaram aqui, é sempre roubada.



> # Para cada pessoa preciso buscar o e-mail e o telefone mais recente caso
> exista, #me preocupo com joins...

Se se preocupa com junções, evite o uso desses ids quando possível,
costuma ser muito mais relevante que normalização.

A meu ver bastariam duas tabelas, uma com id_pessoa e o número de
telefone, outra com id_pessoa e o endereço de correio eletrônico.

Mas de novo, é difícil prestar consultoria voluntariamente e por lista
de discussão.


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

Re: [pgbr-geral] NORMALIZAÇÃO

[Aldemir Vieira]

Você já tentou fazer uma engenharia reversa (desconstrução) da
funcionalidade de contato do GMAIL? Eles, assim como diversos outros
"contatos" utilizam uma "lógica" parecida.

Da forma que fez, sem domínio fixo, sua solução é similar e porém
escalonável (3-Fax, 4-ICQ, etc). O grande "porém", são as regras de
validações e as máscaras, POREM, esse atributo pode fazer parte dessa sua
tabela de tipos, POREM a evolução da regra e a aplicação da máscara
dependeriam da linguagem de programação escolhida para a camada de negócio e
interface, respectivamente.

No mais, acredito que está no caminho certo.

2008/6/2 junior Prado <[EMAIL PROTECTED]>:

>
> 2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:
>
> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
>> > Galera,
>> >
>> > Pensando em contatos de pessoas, procurando normalizar criei a seguinte
>> > estrutura:
>> >
>> > TIPO CONTATO
>> > Idnome_contato
>> > 1  telefone
>> > 2  e-mail
>> >
>> > PESSOA
>> > Id nome_pessoa
>> > 1   Zé
>> > 2   João
>> >
>> > PESSOA CONTATO
>> > id  id_pessoa  id_contato  des_contato_pessoa
>> > 1   11 9874-4561
>> > 2   21 4567-6541
>> > 3   12 [EMAIL PROTECTED]
>>
>> Não entendi a lógica, e fica difícil manter a consistência, não?
>>
>> Talvez o que você tenha querido dizer é qual a forma de contato
>> preferida da pessoa?
>>
>>
>> > É a melhor forma de normalizar?
>>
>> Parece que não, mas fica difícil dizer sem o resto do projeto.
>>
>>
>> > Poderia criar um campo em pessoa contato indicando tipo de contato(T -
>> > telefone E - e-mail) eliminando a tabela tipo de contato, com isto
>> ganharia
>> > desempenho?
>>
>> Desempenho não parece ser um problema, então para que se preocupar com
>> isso antes da hora?
>>
>> Essa relação tipo_contato parece desnecessária.  Aliás o atributo
>> pessoa_contato.id_contato parece redundante, não?  E poderia ser
>> substituído tranqüilamente com um atributo nome_contato com uma
>> restrição de integridade IN.
>>
>>
>> > Quando é melhor fazer um tabelão do que normalizar?
>>
>> Quando você tem um problema de desempenho do tamanho da Serra do Mar,
>> e já esgotou todas outras alternativas.
>>
>> --
>> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
>> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
>> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
> Não entendi a lógica, e fica difícil manter a consistência, não?
>
> Talvez o que você tenha querido dizer é qual a forma de contato
> preferida da pessoa?
>
> #A lógica é armazenar todos os contatos de uma pessoa, tendo 0..n e-mail ou
> 0..n #telefones
>
>
> > É a melhor forma de normalizar?
>
> Parece que não, mas fica difícil dizer sem o resto do projeto.
> # Está normalizado, fico em duvida se é necessário uma normalização
> detalhada.
>
>
> > Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> > telefone E - e-mail) eliminando a tabela tipo de contato, com isto
> ganharia
> > desempenho?
>
> Desempenho não parece ser um problema, então para que se preocupar com
> isso antes da hora?
> # Para cada pessoa preciso buscar o e-mail e o telefone mais recente caso
> exista, #me preocupo com joins...
>
> Essa relação tipo_contato parece desnecessária.  Aliás o atributo
> pessoa_contato.id_contato parece redundante, não?  E poderia ser
> substituído tranqüilamente com um atributo nome_contato com uma
> restrição de integridade IN.
> #Não entendi, acredito que isto já está feito
>
> > Quando é melhor fazer um tabelão do que normalizar?
>
> Quando você tem um problema de desempenho do tamanho da Serra do Mar,
> e já esgotou todas outras alternativas.
>
>
>
>
> --
> VALTER CEZAR PRADO JUNIOR
> GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
> ANALISTA DE SISTEMAS - BYSAT
> DBA / PROJETISTA DE SISTEMAS - PBH
>
> Sem saber como fazer ele fez!
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
Forte abraço,
Aldemir Vieira
___
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 com Indice Composto

[Vi]

A tabela contém muitos registros, por isso a criação de indice.
Estou usando indice composto (para a linha grifada em resposta anterior).
Passar a estrutura da tabela, fica complicado.
A consulta eh a seguinte:
SELECT count(distinct(rdelrde)), count(tid), sum(tvlr)
FROM titulo, rdel, grrde, grp, csk
WHERE
(ttctr = rdelctr) and
(grpcsk   = cskid ) and
(rdelrde = grrderde) and
(grrdegrp = grpid) and
(cskid = 5) and
(tsac = '70064993000140') and
(tpgt is null) and
(tvct >= '2008-05-14 00:00:00') and
(tvct <= '2008-07-14 00:00:00')
LIMIT 1;
Mas a consulta eh pra retornar informações sobre qtas lojas,  qtos titulos
e o valor do titulo quando a condicao  for verdadeira.

Em 02/06/08, William Leite Araújo <[EMAIL PROTECTED]>
escreveu:
>
> Índices funcionam bem para comparar se é igual ou não. Usar um campo
> com valores null não costuma ser muito bom mesmo. Qual tipo de índice está
> usando? Poderia dar mais detalhes? Tipo estrutura da tabela / consulta?
>
> 2008/6/2 Vi <[EMAIL PROTECTED]>:
>
>> Bom dia!!!
>> Estou precisando de uma ajuda com indice composto, criei um indice
>> composto em uma tabela, para otimizar a consulta, mas a consulta não esta
>> utilizando o indice. Só para esclarecer melhor, um dos campos que compõe o
>> indice é do tipo varchar (esse campo  recebe apenas números) e o outro e do
>> tipo timestamp (esse campo é utilizado para uma comparação de valor nulo),
>> estou usando o explain para analizar a consulta, jah tentei converter o tipo
>> timestamp para text , e não obtive o retorno esperado, ele continua usando o
>> filter para a consulta.
>> Aguardo retorno!
>>
>> Obrigada!
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> William Leite Araújo
> Analista de Banco de Dados - QualiConsult
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 Leonardo Cezar <[EMAIL PROTECTED]>:
> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
>> Quando é melhor fazer um tabelão do que normalizar?
>
> Quando voce utiliza consultas analíticas.

E olhe lá, Leonardo, e olhe lá...


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

Re: [pgbr-geral] NORMALIZAÇÃO

[junior Prado]

Leo,

Não. Voce está confundindo informação de domínios diferentes em
PESSOA_CONTATO, de forma que pra voce aplicar qualquer restrição em
des_contato_pessoa voce precisa conhecer o tipod e pessoa. Em resumo
(o assunto é longo) voce não poderia validar o próprio domínio de seu
tipo contato. Por exemplo:

ALTER TABLE "PESSOA_CONTACTO"
  ADD CONSTRIANT check_email
  CHECK (des_contato_pessoa ~ '^[a-z]{3,[EMAIL PROTECTED],}$');

.. não funcionaria.

Será se é necessário este detalhamento -> CHECK (des_contato_pessoa ~
'^[a-z]{3,[EMAIL PROTECTED],}$'); Ou poderia colocar um campo na tabela tipo 
contato
com descricao_mascara, sendo uma expressao regular e deixar a aplicação usar
este campo para validar se grava ou nao na tabela pessoa contato?

> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> telefone E - e-mail) eliminando a tabela tipo de contato, com isto
ganharia
> desempenho?

Não.
Verifiquei usando o explain e vc tem toda razão.

> Sugestões, dicas, artigos?

Livros: Introdução a Sistemas de Banco de dados, CJ,Date;

> Quando é melhor fazer um tabelão do que normalizar?

Quando voce utiliza consultas analíticas.
Em ambientes OLTP, sinceramente desconheço.

-Leo

2008/6/2 Leonardo Cezar <[EMAIL PROTECTED]>:

> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> > Galera,
> >
> > Pensando em contatos de pessoas, procurando normalizar criei a seguinte
> > estrutura:
> >
> > TIPO CONTATO
> > Idnome_contato
> > 1  telefone
> > 2  e-mail
> >
> > PESSOA
> > Id nome_pessoa
> > 1   Zé
> > 2   João
> >
> > PESSOA CONTATO
> > id  id_pessoa  id_contato  des_contato_pessoa
> > 1   11 9874-4561
> > 2   21 4567-6541
> > 3   12 [EMAIL PROTECTED]
> >
> > Perguntas:
> >
> > É a melhor forma de normalizar?
>
> Não. Voce está confundindo informação de domínios diferentes em
> PESSOA_CONTATO, de forma que pra voce aplicar qualquer restrição em
> des_contato_pessoa voce precisa conhecer o tipod e pessoa. Em resumo
> (o assunto é longo) voce não poderia validar o próprio domínio de seu
> tipo contato. Por exemplo:
>
> ALTER TABLE "PESSOA_CONTACTO"
>   ADD CONSTRIANT check_email
>   CHECK (des_contato_pessoa ~ '^[a-z]{3,[EMAIL PROTECTED],}$');
>
> .. não funcionaria.
>
> > Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> > telefone E - e-mail) eliminando a tabela tipo de contato, com isto
> ganharia
> > desempenho?
>
> Não.
>
> > Sugestões, dicas, artigos?
>
> Livros: Introdução a Sistemas de Banco de dados, CJ,Date;
>
> > Quando é melhor fazer um tabelão do que normalizar?
>
> Quando voce utiliza consultas analíticas.
> Em ambientes OLTP, sinceramente desconheço.
>
> -Leo
> --
> Leonardo Cezar
> http://pgcon.postgresql.org.br
> http://www.dextra.com.br/postgres
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
VALTER CEZAR PRADO JUNIOR
GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
ANALISTA DE SISTEMAS - BYSAT
DBA / PROJETISTA DE SISTEMAS - PBH

Sem saber como fazer ele fez!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Mozart Hasse]

junior Prado,

Respostas:

> É a melhor forma de normalizar?

Depende do que dizem seus requisitos, de quantos registros suas tabelas vão
ter, quantos contatos cada pessoa terá em média, quais índices você vai
criar e qual o desempenho esperado para isso tudo quando você souber que
tipos de consultas e atualizações vai fazer.

> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> telefone E - e-mail) eliminando a tabela tipo de contato, com isto ganharia
> desempenho?

Bom, primeiro decida se o relacionamento entre contatos e pessoas é de
um-para-um ou um-para-N, o mesmo valendo para cada tipo de contato que você
pretende inventar. Se for tudo um-para-(zero-ou-)um, não tem motivo para
esquartejar a tabela desse jeito.

> Sugestões, dicas, artigos?

Sugiro que defina claramente seus requisitos antes de sair modelando. Dúvidas
sobre cardinalidade não deveriam existir nessa etapa de modelagem.

> Quando é melhor fazer um tabelão do que normalizar?

Quando você testar desempenho dos dois jeitos e o tabelão se sair melhor.
Minha experiência me mostrou que um tabelão quase nunca se sai melhor,
exceto quando ele é comparado com uma péssima normalização.

Atenciosamente,

Mozart Hasse


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

Re: [pgbr-geral] Dúvida sobre como passar um array par a uma SP em pl/pgsql

[Rúben Lício]

SELECT sp_teste(ARRAY[1,2]); FUNCIONOU
SELECT sp_teste('{1,2}'); NÃO FUNCIONOU

Obrigado.

Rúben

On Mon, Jun 2, 2008 at 12:00 PM, Leonardo Cezar <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 11:19 AM, Rúben Lício <[EMAIL PROTECTED]> wrote:
>> Bom dia,
>>
>> Estou tentando criar um SP no postgres que recebe um array como
>> parametro, mas estou com problemas na hora de testar isso.
>> A declaração da SP é:
>>
>> CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[])
>>
>> Estou chamando essa SP como:
>>
>> select sp_teste({1234, 4321});
>
> SELECT sp_teste(ARRAY[1,2]);
> OU
> SELECT sp_teste('{1,2}');
>
> -Leo
> --
> Leonardo Cezar
> http://pgcon.postgresql.org.br
> http://www.dextra.com.br/postgres
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Rúben Lício Reis
Cybernet Latino América
www.cybernetla.com

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

Re: [pgbr-geral] NORMALIZAÇÃO

[junior Prado]

2008/6/2 Leandro DUTRA <[EMAIL PROTECTED]>:

> 2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> > Galera,
> >
> > Pensando em contatos de pessoas, procurando normalizar criei a seguinte
> > estrutura:
> >
> > TIPO CONTATO
> > Idnome_contato
> > 1  telefone
> > 2  e-mail
> >
> > PESSOA
> > Id nome_pessoa
> > 1   Zé
> > 2   João
> >
> > PESSOA CONTATO
> > id  id_pessoa  id_contato  des_contato_pessoa
> > 1   11 9874-4561
> > 2   21 4567-6541
> > 3   12 [EMAIL PROTECTED]
>
> Não entendi a lógica, e fica difícil manter a consistência, não?
>
> Talvez o que você tenha querido dizer é qual a forma de contato
> preferida da pessoa?
>
>
> > É a melhor forma de normalizar?
>
> Parece que não, mas fica difícil dizer sem o resto do projeto.
>
>
> > Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> > telefone E - e-mail) eliminando a tabela tipo de contato, com isto
> ganharia
> > desempenho?
>
> Desempenho não parece ser um problema, então para que se preocupar com
> isso antes da hora?
>
> Essa relação tipo_contato parece desnecessária.  Aliás o atributo
> pessoa_contato.id_contato parece redundante, não?  E poderia ser
> substituído tranqüilamente com um atributo nome_contato com uma
> restrição de integridade IN.
>
>
> > Quando é melhor fazer um tabelão do que normalizar?
>
> Quando você tem um problema de desempenho do tamanho da Serra do Mar,
> e já esgotou todas outras alternativas.
>
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Não entendi a lógica, e fica difícil manter a consistência, não?

Talvez o que você tenha querido dizer é qual a forma de contato
preferida da pessoa?

#A lógica é armazenar todos os contatos de uma pessoa, tendo 0..n e-mail ou
0..n #telefones


> É a melhor forma de normalizar?

Parece que não, mas fica difícil dizer sem o resto do projeto.
# Está normalizado, fico em duvida se é necessário uma normalização
detalhada.


> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> telefone E - e-mail) eliminando a tabela tipo de contato, com isto
ganharia
> desempenho?

Desempenho não parece ser um problema, então para que se preocupar com
isso antes da hora?
# Para cada pessoa preciso buscar o e-mail e o telefone mais recente caso
exista, #me preocupo com joins...

Essa relação tipo_contato parece desnecessária.  Aliás o atributo
pessoa_contato.id_contato parece redundante, não?  E poderia ser
substituído tranqüilamente com um atributo nome_contato com uma
restrição de integridade IN.
#Não entendi, acredito que isto já está feito

> Quando é melhor fazer um tabelão do que normalizar?

Quando você tem um problema de desempenho do tamanho da Serra do Mar,
e já esgotou todas outras alternativas.




-- 
VALTER CEZAR PRADO JUNIOR
GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
ANALISTA DE SISTEMAS - BYSAT
DBA / PROJETISTA DE SISTEMAS - PBH

Sem saber como fazer ele fez!
___
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 com Indice Composto

[Vi]

Bom esse eh o explain;
Onde eu preciso que seja usado o indice esta grifado.

Limit  (cost=8.96..8.97 rows=1 width=18)
   ->  Aggregate  (cost=8.96..8.97 rows=1 width=18)
 ->  Nested Loop  (cost=0.00..8.94 rows=1 width=18)
   ->  Nested Loop  (cost=0.00..6.66 rows=1 width=22)
 ->  Nested Loop  (cost=0.00..6.05 rows=1 width=22)
   ->  Nested Loop  (cost=0.00..5.77 rows=1
width=18)
 ->  Index Scan using idx_tvct on tit
(cost=0.00..3.49 rows=1 width=18)
   Index Cond: ((tvct = '2008-05-14
00:00:00'::timestamp without time zone) AND (tvct <= '2008-07-14
00:00:00'::timestamp without time zone))
   Filter: (((tsac)::text =
'70064993000140'::text) AND (tpgt IS NULL))
 ->  Index Scan using rdede on rdel
(cost=0.00..2.27 rows=1 width=8)
   Index Cond: (t.tctr = rdel.rdelctr)
   ->  Index Scan using grprrde_grprgrp on grpr
(cost=0.00..0.27 rows=1 width=8)
 Index Cond: (rdel.rdelrde = grpr.grprrde)
 ->  Index Scan using grpgr_pkey on grpgr
(cost=0.00..0.60 rows=1 width=8)
   Index Cond: (grpgrrde.grpgrrdegrp =
grpgr.grpgrid)
   Filter: (5 = grpgrcsk)
   ->  Index Scan using csk_pkey on csk  (cost=0.00..2.27 rows=1
width=4)
 Index Cond: (cskid = 5)

Em 02/06/08, jota. comm <[EMAIL PROTECTED]> escreveu:
>
>
> Olá,
>
> Você pode colocar o comando de criação do índice e o explain da consulta?
>
> []s
>
> 2008/6/2 Vi <[EMAIL PROTECTED]>:
>
>> Bom dia!!!
>> Estou precisando de uma ajuda com indice composto, criei um indice
>> composto em uma tabela, para otimizar a consulta, mas a consulta não esta
>> utilizando o indice. Só para esclarecer melhor, um dos campos que compõe o
>> indice é do tipo varchar (esse campo  recebe apenas números) e o outro e do
>> tipo timestamp (esse campo é utilizado para uma comparação de valor nulo),
>> estou usando o explain para analizar a consulta, jah tentei converter o tipo
>> timestamp para text , e não obtive o retorno esperado, ele continua usando o
>> filter para a consulta.
>> Aguardo retorno!
>>
>> Obrigada!
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> João Paulo
> www.dextra.com.br/postgres
> PostgreSQL
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre como passar um array par a uma SP em pl/pgsql

[William Leite Araújo]

2008/6/2 Rúben Lício <[EMAIL PROTECTED]>:

> Bom dia,
>
> Estou tentando criar um SP no postgres que recebe um array como
> parametro, mas estou com problemas na hora de testar isso.
> A declaração da SP é:
>
> CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[])
>
> Estou chamando essa SP como:
>
> select sp_teste({1234, 4321});


*SELECT* sp_teste('{1234,4321}'::integer[]);


>
>
> isso gera um:
>
> ERROR:  syntax error at or near "{"
>
> Como posso fazer para passar um array a essa SP para testa-la??
>
> Obrigado.
>
> --
> Rúben Lício Reis
>
> Linux user #433535
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
William Leite Araújo
Analista de Banco de Dados - QualiConsult
___
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 com Indice Composto

[William Leite Araújo]

Índices funcionam bem para comparar se é igual ou não. Usar um campo com
valores null não costuma ser muito bom mesmo. Qual tipo de índice está
usando? Poderia dar mais detalhes? Tipo estrutura da tabela / consulta?

2008/6/2 Vi <[EMAIL PROTECTED]>:

> Bom dia!!!
> Estou precisando de uma ajuda com indice composto, criei um indice composto
> em uma tabela, para otimizar a consulta, mas a consulta não esta utilizando
> o indice. Só para esclarecer melhor, um dos campos que compõe o indice é do
> tipo varchar (esse campo  recebe apenas números) e o outro e do tipo
> timestamp (esse campo é utilizado para uma comparação de valor nulo), estou
> usando o explain para analizar a consulta, jah tentei converter o tipo
> timestamp para text , e não obtive o retorno esperado, ele continua usando o
> filter para a consulta.
> Aguardo retorno!
>
> Obrigada!
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
William Leite Araújo
Analista de Banco de Dados - QualiConsult
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre como passar um array p ara uma SP em pl/pgsql

[Ribamar Sousa]

Teste essa:

CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[]) returns integer[]
as
$$
begin

return teste_array;
end;
$$
language plpgsql;

select sp_teste('{123}')


2008/6/2 Rúben Lício <[EMAIL PROTECTED]>:

> Bom dia,
>
> Estou tentando criar um SP no postgres que recebe um array como
> parametro, mas estou com problemas na hora de testar isso.
> A declaração da SP é:
>
> CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[])
>
> Estou chamando essa SP como:
>
> select sp_teste({1234, 4321});
>
> isso gera um:
>
> ERROR:  syntax error at or near "{"
>
> Como posso fazer para passar um array a essa SP para testa-la??
>
> Obrigado.
>
> --
> Rúben Lício Reis
>
> Linux user #433535
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre como passar um array p ara uma SP em pl/pgsql

[Osvaldo Rosario Kussama]

Rúben Lício escreveu:
> Bom dia,
> 
> Estou tentando criar um SP no postgres que recebe um array como
> parametro, mas estou com problemas na hora de testar isso.
> A declaração da SP é:
> 
> CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[])
> 
> Estou chamando essa SP como:
> 
> select sp_teste({1234, 4321});
> 
> isso gera um:
> 
> ERROR:  syntax error at or near "{"
> 
> Como posso fazer para passar um array a essa SP para testa-la??
> 


Tente:
SELECT sp_teste('{1234, 4321}'::int[]);

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

Re: [pgbr-geral] NORMALIZAÇÃO

[Leonardo Cezar]

2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> Galera,
>
> Pensando em contatos de pessoas, procurando normalizar criei a seguinte
> estrutura:
>
> TIPO CONTATO
> Idnome_contato
> 1  telefone
> 2  e-mail
>
> PESSOA
> Id nome_pessoa
> 1   Zé
> 2   João
>
> PESSOA CONTATO
> id  id_pessoa  id_contato  des_contato_pessoa
> 1   11 9874-4561
> 2   21 4567-6541
> 3   12 [EMAIL PROTECTED]
>
> Perguntas:
>
> É a melhor forma de normalizar?

Não. Voce está confundindo informação de domínios diferentes em
PESSOA_CONTATO, de forma que pra voce aplicar qualquer restrição em
des_contato_pessoa voce precisa conhecer o tipod e pessoa. Em resumo
(o assunto é longo) voce não poderia validar o próprio domínio de seu
tipo contato. Por exemplo:

ALTER TABLE "PESSOA_CONTACTO"
   ADD CONSTRIANT check_email
   CHECK (des_contato_pessoa ~ '^[a-z]{3,[EMAIL PROTECTED],}$');

.. não funcionaria.

> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> telefone E - e-mail) eliminando a tabela tipo de contato, com isto ganharia
> desempenho?

Não.

> Sugestões, dicas, artigos?

Livros: Introdução a Sistemas de Banco de dados, CJ,Date;

> Quando é melhor fazer um tabelão do que normalizar?

Quando voce utiliza consultas analíticas.
Em ambientes OLTP, sinceramente desconheço.

-Leo
-- 
Leonardo Cezar
http://pgcon.postgresql.org.br
http://www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] NORMALIZAÇÃO

[Leandro DUTRA]

2008/6/2 junior Prado <[EMAIL PROTECTED]>:
> Galera,
>
> Pensando em contatos de pessoas, procurando normalizar criei a seguinte
> estrutura:
>
> TIPO CONTATO
> Idnome_contato
> 1  telefone
> 2  e-mail
>
> PESSOA
> Id nome_pessoa
> 1   Zé
> 2   João
>
> PESSOA CONTATO
> id  id_pessoa  id_contato  des_contato_pessoa
> 1   11 9874-4561
> 2   21 4567-6541
> 3   12 [EMAIL PROTECTED]

Não entendi a lógica, e fica difícil manter a consistência, não?

Talvez o que você tenha querido dizer é qual a forma de contato
preferida da pessoa?


> É a melhor forma de normalizar?

Parece que não, mas fica difícil dizer sem o resto do projeto.


> Poderia criar um campo em pessoa contato indicando tipo de contato(T -
> telefone E - e-mail) eliminando a tabela tipo de contato, com isto ganharia
> desempenho?

Desempenho não parece ser um problema, então para que se preocupar com
isso antes da hora?

Essa relação tipo_contato parece desnecessária.  Aliás o atributo
pessoa_contato.id_contato parece redundante, não?  E poderia ser
substituído tranqüilamente com um atributo nome_contato com uma
restrição de integridade IN.


> Quando é melhor fazer um tabelão do que normalizar?

Quando você tem um problema de desempenho do tamanho da Serra do Mar,
e já esgotou todas outras alternativas.

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

Re: [pgbr-geral] Ajuda com Indice Composto

[Leonardo Cezar]

2008/6/2 Vi <[EMAIL PROTECTED]>:
> Bom dia!!!
> Estou precisando de uma ajuda com indice composto, criei um indice composto
> em uma tabela, para otimizar a consulta, mas a consulta não esta utilizando
> o indice. Só para esclarecer melhor, um dos campos que compõe o indice é do
> tipo varchar (esse campo  recebe apenas números) e o outro e do tipo
> timestamp (esse campo é utilizado para uma comparação de valor nulo), estou
> usando o explain para analizar a consulta, jah tentei converter o tipo
> timestamp para text , e não obtive o retorno esperado, ele continua usando o
> filter para a consulta.
> Aguardo retorno!

Quais:
 * Cardinalidade da relação;
 * Explicação da Consulta;
 * DDL da tabela;

-Leo
-- 
Leonardo Cezar
http://pgcon.postgresql.org.br
http://www.dextra.com.br/postgres
___
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 com Indice Composto

[jota . comm]

Olá,

Você pode colocar o comando de criação do índice e o explain da consulta?

[]s

2008/6/2 Vi <[EMAIL PROTECTED]>:

> Bom dia!!!
> Estou precisando de uma ajuda com indice composto, criei um indice composto
> em uma tabela, para otimizar a consulta, mas a consulta não esta utilizando
> o indice. Só para esclarecer melhor, um dos campos que compõe o indice é do
> tipo varchar (esse campo  recebe apenas números) e o outro e do tipo
> timestamp (esse campo é utilizado para uma comparação de valor nulo), estou
> usando o explain para analizar a consulta, jah tentei converter o tipo
> timestamp para text , e não obtive o retorno esperado, ele continua usando o
> filter para a consulta.
> Aguardo retorno!
>
> Obrigada!
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre como passar um array p ara uma SP em pl/pgsql

[Leonardo Cezar]

On Mon, Jun 2, 2008 at 11:19 AM, Rúben Lício <[EMAIL PROTECTED]> wrote:
> Bom dia,
>
> Estou tentando criar um SP no postgres que recebe um array como
> parametro, mas estou com problemas na hora de testar isso.
> A declaração da SP é:
>
> CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[])
>
> Estou chamando essa SP como:
>
> select sp_teste({1234, 4321});

SELECT sp_teste(ARRAY[1,2]);
OU
SELECT sp_teste('{1,2}');

-Leo
-- 
Leonardo Cezar
http://pgcon.postgresql.org.br
http://www.dextra.com.br/postgres
___
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 com Indice Composto

[Sebastian SWC]

2008/6/2 Vi <[EMAIL PROTECTED]>:
> Bom dia!!!

Bom dia!

> Estou precisando de uma ajuda com indice composto, criei um indice composto
> em uma tabela, para otimizar a consulta, mas a consulta não esta utilizando
> o indice. Só para esclarecer melhor, um dos campos que compõe o indice é do
> tipo varchar (esse campo  recebe apenas números) e o outro e do tipo
> timestamp (esse campo é utilizado para uma comparação de valor nulo), estou
> usando o explain para analizar a consulta, jah tentei converter o tipo
> timestamp para text , e não obtive o retorno esperado, ele continua usando o
> filter para a consulta.
> Aguardo retorno!

Mostra o explain da tua consulta.

-- 
Sebastian SWC
http://sebastianswc.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 com Indice Composto

[Leandro DUTRA]

2008/6/2 Vi <[EMAIL PROTECTED]>:
> Estou precisando de uma ajuda com indice composto, criei um indice composto
> em uma tabela, para otimizar a consulta, mas a consulta não esta utilizando
> o indice.

Há várias razões possíveis, a principal sendo tabela pequena demais.
Sem mais informações é impossível ajudar.

Por favor divida seu texto melhor em frases e parágrafos, está de
tirar o fôlego.

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

Re: [pgbr-geral] Ajuda com Indice Composto

[Dickson Guedes]

Vi escreveu:
> Bom dia!!!
> Estou precisando de uma ajuda com indice composto, criei um indice 
> composto em uma tabela, para otimizar a consulta, mas a consulta não 
> esta utilizando o indice. 

Bom dia.

Você poderia nos enviar o EXPLAIN da sua consulta e a estrutura das 
tabelas envolvidas?

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

[pgbr-geral] Dúvida sobre como passar um array par a uma SP em pl/pgsql

[Rúben Lício]

Bom dia,

Estou tentando criar um SP no postgres que recebe um array como
parametro, mas estou com problemas na hora de testar isso.
A declaração da SP é:

CREATE OR REPLACE FUNCTION sp_teste(teste_array integer[])

Estou chamando essa SP como:

select sp_teste({1234, 4321});

isso gera um:

ERROR:  syntax error at or near "{"

Como posso fazer para passar um array a essa SP para testa-la??

Obrigado.

-- 
Rúben Lício Reis

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

[pgbr-geral] Ajuda com Indice Composto

[Vi]

Bom dia!!!
Estou precisando de uma ajuda com indice composto, criei um indice composto
em uma tabela, para otimizar a consulta, mas a consulta não esta utilizando
o indice. Só para esclarecer melhor, um dos campos que compõe o indice é do
tipo varchar (esse campo  recebe apenas números) e o outro e do tipo
timestamp (esse campo é utilizado para uma comparação de valor nulo), estou
usando o explain para analizar a consulta, jah tentei converter o tipo
timestamp para text , e não obtive o retorno esperado, ele continua usando o
filter para a consulta.
Aguardo retorno!

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

[pgbr-geral] NORMALIZAÇÃO

[junior Prado]

Galera,

Pensando em contatos de pessoas, procurando normalizar criei a seguinte
estrutura:

TIPO CONTATO
Idnome_contato
1  telefone
2  e-mail

PESSOA
Id nome_pessoa
1   Zé
2   João

PESSOA CONTATO
id  id_pessoa  id_contato  des_contato_pessoa
1   11 9874-4561
2   21 4567-6541
3   12 [EMAIL PROTECTED]

Perguntas:

É a melhor forma de normalizar?
Poderia criar um campo em pessoa contato indicando tipo de contato(T -
telefone E - e-mail) eliminando a tabela tipo de contato, com isto ganharia
desempenho?
Sugestões, dicas, artigos?
Quando é melhor fazer um tabelão do que normalizar?


-- 
VALTER CEZAR PRADO JUNIOR
GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP
ANALISTA DE SISTEMAS - BYSAT
DBA / PROJETISTA DE SISTEMAS - PBH

Sem saber como fazer ele fez!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [Fraude!] [Desinfectado] Re : [Fraude!] [Desinfectado] Efeito da vari ável ON_ERROR_ROLLBACK

[Álvaro Guimarães]

Opa, muito obrigado pela ajuda William, Osvaldo, Jota e Emerson.

2008/6/2 William Leite Araújo <[EMAIL PROTECTED]>:

>Muito bem. Caso ainda esteja com o problema, converta o arquivo de
> backup para o modo texto, usando o pg_restore sem especificar o banco de
> dados, mas um arquivo, por exemplo :
>
>  pg_restpres -F c [arquivo de backup] > novo_arquivo.sql
>
>
> Em seguida, use o psql...
>
>
> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>
>> Olá, Álvaro
>>
>> Quando o parâmetro tiver setado para ON, ele ignora os erros e continua a
>> sua transação sem abortar (rollback) o processo. Isso funciona em uma sessão
>> interativa (psql). Interativo neste caso refere-se a sessão e não um valor
>> para o parâmetro. Quando a execução ocorre a partir de um arquivo isso não
>> acontece e o erro não é ignorado (acontece rollback) como ocorre na sessão.
>>
>>
>> Espero ter ajudado.
>>
>> []s
>>
>>
>>
>> 2008/5/29 Álvaro Guimarães <[EMAIL PROTECTED]>:
>>
>>> Relendo a man page...
>>>
>>> ON_ERROR_ROLLBACK
   When on, if a statement in  a  transaction  block
 generates  an
   error,  the error is ignored and the transaction
 continues. When
   interactive, such errors are only ignored  in
 interactive  ses-
   sions,  and  not  when  reading  script  files.
>>>
>>> Quando setado como "ON", quando uma declaração num bloco de transação
>>> gerar um erro, o erro vai ser ignorado e a transação vai continuar. Quando
>>> setado como "interactive" os erros só serão ignorados numa sessão
>>> interativa, e não lendo scripts.
>>>
>>> Ou seja, o tal do ON_ERROR_ROLLBACK era pra funcionar dando um \i dentro
>>> do psql.
>>> Não sei o que fazer. :(
>>>
>>>
>>>
>>> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>>>
 Olá,

 Por padrão os backups são gerados com copy, a menos que você informe o
 parâmetro -d para usar insert.
 Até onde sei não tem como fazer com o que o copy não aborte a transação
 inteira.


 []s

 2008/5/29 Álvaro Guimarães <[EMAIL PROTECTED]>:

> Meu backup é gerado com pg_dump -Fc que no manual ta falando que é uma
> forma comprimida de backup. Então no caso o -Fc tá gerando backups com 
> COPY.
> Seria isso né?
> E será que tem como fazer com que o COPY não aborte a transação
> inteira?
>
>
> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>
>> Olá, Álvaro
>>
>> Uma sessão interativa é uma sessão psql, por exemplo:
>>
>> Se eu digitar: psql meu_banco eu abro uma sessão interativa para o
>> banco meu_banco.
>>
>> O seu backup é feito com o comando copy? Se for feito com o copy e um
>> erro for gerado ele aborta toda a transação, e isso implica que a sua 
>> tabela
>> não sera carregada.
>>
>> Espero ter ajudado.
>>
>> []s
>>
>> 2008/5/29 Álvaro Guimarães <[EMAIL PROTECTED]>:
>>
>> Meu problema em usar o pg_restore é o mesmo.
>>> Não quero rollback caso retorne erros e pelo que li ele não usa as
>>> variáveis do psql.
>>> Desculpe minha ignorancia. O que exatamente seria uma sessão
>>> interativa?
>>> Meu problema é que eu perco os dados de uma tabela inteira no backup
>>> porquê se uma instrução gerar um erro o postgresql da rollback nela. O
>>> script continua rodando depois disso então o ON_ERROR_STOP não é a 
>>> solução
>>> do meu problema.
>>>
>>> Muito obrigado pelas respostas imediatas.
>>>
>>>
>>> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>>>
 Olá, Álvaro e Émerson

 Corrigindo a minha resposta:

 Segundo a documentação:
 ON_ERROR_ROLLBACK

 When on, if a statement in a transaction block generates an error,
 the error is ignored and the transaction continues. When
 interactive, such errors are only ignored in interactive sessions,
 and not when reading script files. When off (the default), a
 statement in a transaction block that generates an error aborts the 
 entire
 transaction. The on_error_rollback-on mode works by issuing an implicit
 SAVEPOINT for you, just before each command that is in a
 transaction block, and rolls back to the savepoint on error.
 Isto significa que os erros são apenas ignorados com
 ON_ERROR_ROLLBACK ON em sessões interativas e não quando são lidas de 
 um
 arquivo de script.

 Neste caso você pode tentar usar o ON_ERROR_STOP, mas como comentei
 no e-mail anterior nunca usei com em bloco de transação com BEGIN e 
 COMMIT
 em um arquivo de script, então precisaria ser testado.

 Espero ter ajudado.

 []s

 2008/5/29 jota. comm <[EMAIL PROTECTED]>:

 Olá,
>
> Para recuperar backup binário você precisa usar o pg_rest

Re: [pgbr-geral] [Fraude!] [Desinfectado] Re: [ Fraude!] [Desinfectado] Efeito da variável ON _ERROR_ROLLBACK

[William Leite Araújo]

   Muito bem. Caso ainda esteja com o problema, converta o arquivo de backup
para o modo texto, usando o pg_restore sem especificar o banco de dados, mas
um arquivo, por exemplo :

 pg_restpres -F c [arquivo de backup] > novo_arquivo.sql


Em seguida, use o psql...

2008/5/29 jota. comm <[EMAIL PROTECTED]>:

> Olá, Álvaro
>
> Quando o parâmetro tiver setado para ON, ele ignora os erros e continua a
> sua transação sem abortar (rollback) o processo. Isso funciona em uma sessão
> interativa (psql). Interativo neste caso refere-se a sessão e não um valor
> para o parâmetro. Quando a execução ocorre a partir de um arquivo isso não
> acontece e o erro não é ignorado (acontece rollback) como ocorre na sessão.
>
>
> Espero ter ajudado.
>
> []s
>
>
>
> 2008/5/29 Álvaro Guimarães <[EMAIL PROTECTED]>:
>
>> Relendo a man page...
>>
>> ON_ERROR_ROLLBACK
>>>   When on, if a statement in  a  transaction  block
>>> generates  an
>>>   error,  the error is ignored and the transaction continues.
>>> When
>>>   interactive, such errors are only ignored  in  interactive
>>> ses-
>>>   sions,  and  not  when  reading  script  files.
>>
>> Quando setado como "ON", quando uma declaração num bloco de transação
>> gerar um erro, o erro vai ser ignorado e a transação vai continuar. Quando
>> setado como "interactive" os erros só serão ignorados numa sessão
>> interativa, e não lendo scripts.
>>
>> Ou seja, o tal do ON_ERROR_ROLLBACK era pra funcionar dando um \i dentro
>> do psql.
>> Não sei o que fazer. :(
>>
>>
>>
>> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>>
>>> Olá,
>>>
>>> Por padrão os backups são gerados com copy, a menos que você informe o
>>> parâmetro -d para usar insert.
>>> Até onde sei não tem como fazer com o que o copy não aborte a transação
>>> inteira.
>>>
>>>
>>> []s
>>>
>>> 2008/5/29 Álvaro Guimarães <[EMAIL PROTECTED]>:
>>>
 Meu backup é gerado com pg_dump -Fc que no manual ta falando que é uma
 forma comprimida de backup. Então no caso o -Fc tá gerando backups com 
 COPY.
 Seria isso né?
 E será que tem como fazer com que o COPY não aborte a transação inteira?


 2008/5/29 jota. comm <[EMAIL PROTECTED]>:

> Olá, Álvaro
>
> Uma sessão interativa é uma sessão psql, por exemplo:
>
> Se eu digitar: psql meu_banco eu abro uma sessão interativa para o
> banco meu_banco.
>
> O seu backup é feito com o comando copy? Se for feito com o copy e um
> erro for gerado ele aborta toda a transação, e isso implica que a sua 
> tabela
> não sera carregada.
>
> Espero ter ajudado.
>
> []s
>
> 2008/5/29 Álvaro Guimarães <[EMAIL PROTECTED]>:
>
> Meu problema em usar o pg_restore é o mesmo.
>> Não quero rollback caso retorne erros e pelo que li ele não usa as
>> variáveis do psql.
>> Desculpe minha ignorancia. O que exatamente seria uma sessão
>> interativa?
>> Meu problema é que eu perco os dados de uma tabela inteira no backup
>> porquê se uma instrução gerar um erro o postgresql da rollback nela. O
>> script continua rodando depois disso então o ON_ERROR_STOP não é a 
>> solução
>> do meu problema.
>>
>> Muito obrigado pelas respostas imediatas.
>>
>>
>> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>>
>>> Olá, Álvaro e Émerson
>>>
>>> Corrigindo a minha resposta:
>>>
>>> Segundo a documentação:
>>> ON_ERROR_ROLLBACK
>>>
>>> When on, if a statement in a transaction block generates an error,
>>> the error is ignored and the transaction continues. When interactive,
>>> such errors are only ignored in interactive sessions, and not when 
>>> reading
>>> script files. When off (the default), a statement in a transaction
>>> block that generates an error aborts the entire transaction. The
>>> on_error_rollback-on mode works by issuing an implicit SAVEPOINT for
>>> you, just before each command that is in a transaction block, and rolls 
>>> back
>>> to the savepoint on error.
>>> Isto significa que os erros são apenas ignorados com
>>> ON_ERROR_ROLLBACK ON em sessões interativas e não quando são lidas de um
>>> arquivo de script.
>>>
>>> Neste caso você pode tentar usar o ON_ERROR_STOP, mas como comentei
>>> no e-mail anterior nunca usei com em bloco de transação com BEGIN e 
>>> COMMIT
>>> em um arquivo de script, então precisaria ser testado.
>>>
>>> Espero ter ajudado.
>>>
>>> []s
>>>
>>> 2008/5/29 jota. comm <[EMAIL PROTECTED]>:
>>>
>>> Olá,

 Para recuperar backup binário você precisa usar o pg_restore, com o
 comando psql não é possível.

 Nunca usei este parâmetro, existe um parâmetro chamado ON_ERROR_STOP
 que você pode habilitar ON ou OFF, quando ON se um comando gerar um 
 erro ele
 aborta o processo, caso OFF ele e