Re: [pgbr-geral] Chave Primaria Composta

2016-08-26 Por tôpico Reijanio Nunes Ribeiro 
Em meu sistema a parte de controle devusuarios é composta nunca tive
problemas
Em 25/08/2016 11:06, "Gustavo"  escreveu:

>
> mais um detalhe, com a chave composta
> evita um monte de triggers para ajuste de algumas informações também,
> erros de programação
> e menos manutenção
> ᐧ
>
> Em 25 de agosto de 2016 10:56, Guimarães Faria Corcete DUTRA, Leandro <
> l...@dutras.org> escreveu:
>
>> 2016-08-25 10:49 GMT-03:00 Gustavo :
>> >
>> > Razão, seria as lendas urbanas que sempre eu via sobre isso...
>>
>> Boa definição.
>>
>>
>> > agora você me dizendo que é uma otima ideia  ja até pensei em uma chave
>> primaria com 3 campos
>>
>> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
>> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
>> chave com, digamos, quatro ou cinco atributos por tabelas filhas
>> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
>> e índices que uma chave natural economiza.
>>
>>
>> > vamos analisar da seguinte maneira. se não fosse uma boa prática não
>> teria essa opção para ser usada no banco de dados...
>>
>> Infelizmente essa lógica nem sempre se aplica.  Por exemplo, herança
>> geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo
>> físico, foi útil para gambiarrar particionamento de tabelas.
>>
>>
>> --
>> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
>> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
>> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
>> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral 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] Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 11:33, Gustavo  escreveu:
>
>  (lembro que eram quase 4 mil tabelas), ouch !
>
> o meu só tem 1.000 tabelas...   será que terei problemas com performance 

O número de tabelas não é preponderante no impacto de desempenho.
Alguns softwares/sistemas muito bem escritos conseguem ter uma
quantidade imensa de tabelas mas aplicando no mínimo a 3FN, com cada
tabela/entidade servindo a um propósito específico com poucas
colunas/atributos - muito bem indexadas, claro.

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

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
Depende, lá como eu disse as chaves compostas foram usadas de forma errada,
era uma estrutura de grupo, empresa, filial, unidade +
chave_negocio_tabela, então de cara qualquer PK já tinha no mínimo 5 campos!

Sem contas outras gambiarras que não vem ao caso aqui.



Em 25 de agosto de 2016 11:33, Gustavo 
escreveu:

>  (lembro que eram quase 4 mil tabelas), ouch !
>
> o meu só tem 1.000 tabelas...   será que terei problemas com performance
> 
> ᐧ
>
> Em 25 de agosto de 2016 11:26, Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br> escreveu:
>
>> O maior problema era o inchaço do banco (lembro que eram quase 4 mil
>> tabelas), além da escrita de consultas, um join básico ficava gigante,
>> imagina então algo maior como um SPED!
>>
>> Não tenho mais contato com esse sistema, mas sei que até hoje sofre com
>> problemas de performance nos clientes que usam.
>>
>>
>>
>> Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro <
>> l...@dutras.org> escreveu:
>>
>>> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias <
>>> fabi...@wolaksistemas.com.br>:
>>> >
>>> >> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
>>> >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
>>> >> chave com, digamos, quatro ou cinco atributos por tabelas filhas
>>> >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
>>> >> e índices que uma chave natural economiza.
>>> >
>>> > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível
>>> mais
>>> > baixo da contabilidade (rateio de centro de custo) a chave primária da
>>> > tabela tipo por volta de 15 campos!!!
>>>
>>> Para isso que se criam chaves artificiais, que nem precisam ser
>>> primárias.  Na verdade, o ideal é que não sejam, para que o modelo
>>> fique mais claro e para que nunca se esqueça de definir ao menos uma
>>> chave natural.
>>>
>>>
>>> > Imagine como era trabalhar com uma modelagem desta!
>>>
>>> Com um ferramental adequado, não devia ser problema algum.  Eu fazia
>>> isso com COPYs Cobol, sem dramas.  Vi muito javeiro reclamando, e
>>> questionava-os por que o Java seria tão inferior ao Cobol para fazer
>>> algo tão básico.
>>>
>>> O que tem de ver é se essa propagação de chaves compostas não seria um
>>> problema de armazenamento ou consumo de memória.  Poderia em tese ser,
>>> e geralmente não é, até por evitar criar campos e índices adicionais
>>> para as chaves artificiais.
>>>
>>> Agora, se o ferramental é ruim ou mal usado… infelizmente, uma
>>> situação comum.  Espere problemas com usuários mais ingênuos de ORM,
>>> por exemplo.
>>>
>>>
>>> --
>>> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
>>> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
>>> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
>>> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Gustavo 
 (lembro que eram quase 4 mil tabelas), ouch !

o meu só tem 1.000 tabelas...   será que terei problemas com performance

ᐧ

Em 25 de agosto de 2016 11:26, Fabiano Machado Dias <
fabi...@wolaksistemas.com.br> escreveu:

> O maior problema era o inchaço do banco (lembro que eram quase 4 mil
> tabelas), além da escrita de consultas, um join básico ficava gigante,
> imagina então algo maior como um SPED!
>
> Não tenho mais contato com esse sistema, mas sei que até hoje sofre com
> problemas de performance nos clientes que usam.
>
>
>
> Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro <
> l...@dutras.org> escreveu:
>
>> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias <
>> fabi...@wolaksistemas.com.br>:
>> >
>> >> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
>> >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
>> >> chave com, digamos, quatro ou cinco atributos por tabelas filhas
>> >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
>> >> e índices que uma chave natural economiza.
>> >
>> > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível
>> mais
>> > baixo da contabilidade (rateio de centro de custo) a chave primária da
>> > tabela tipo por volta de 15 campos!!!
>>
>> Para isso que se criam chaves artificiais, que nem precisam ser
>> primárias.  Na verdade, o ideal é que não sejam, para que o modelo
>> fique mais claro e para que nunca se esqueça de definir ao menos uma
>> chave natural.
>>
>>
>> > Imagine como era trabalhar com uma modelagem desta!
>>
>> Com um ferramental adequado, não devia ser problema algum.  Eu fazia
>> isso com COPYs Cobol, sem dramas.  Vi muito javeiro reclamando, e
>> questionava-os por que o Java seria tão inferior ao Cobol para fazer
>> algo tão básico.
>>
>> O que tem de ver é se essa propagação de chaves compostas não seria um
>> problema de armazenamento ou consumo de memória.  Poderia em tese ser,
>> e geralmente não é, até por evitar criar campos e índices adicionais
>> para as chaves artificiais.
>>
>> Agora, se o ferramental é ruim ou mal usado… infelizmente, uma
>> situação comum.  Espere problemas com usuários mais ingênuos de ORM,
>> por exemplo.
>>
>>
>> --
>> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
>> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
>> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
>> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral 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] Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias :
>
>> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
>> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
>> chave com, digamos, quatro ou cinco atributos por tabelas filhas
>> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
>> e índices que uma chave natural economiza.
>
> Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível mais
> baixo da contabilidade (rateio de centro de custo) a chave primária da
> tabela tipo por volta de 15 campos!!!

Para isso que se criam chaves artificiais, que nem precisam ser
primárias.  Na verdade, o ideal é que não sejam, para que o modelo
fique mais claro e para que nunca se esqueça de definir ao menos uma
chave natural.


> Imagine como era trabalhar com uma modelagem desta!

Com um ferramental adequado, não devia ser problema algum.  Eu fazia
isso com COPYs Cobol, sem dramas.  Vi muito javeiro reclamando, e
questionava-os por que o Java seria tão inferior ao Cobol para fazer
algo tão básico.

O que tem de ver é se essa propagação de chaves compostas não seria um
problema de armazenamento ou consumo de memória.  Poderia em tese ser,
e geralmente não é, até por evitar criar campos e índices adicionais
para as chaves artificiais.

Agora, se o ferramental é ruim ou mal usado… infelizmente, uma
situação comum.  Espere problemas com usuários mais ingênuos de ORM,
por exemplo.


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

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
O maior problema era o inchaço do banco (lembro que eram quase 4 mil
tabelas), além da escrita de consultas, um join básico ficava gigante,
imagina então algo maior como um SPED!

Não tenho mais contato com esse sistema, mas sei que até hoje sofre com
problemas de performance nos clientes que usam.



Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br>:
> >
> >> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
> >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
> >> chave com, digamos, quatro ou cinco atributos por tabelas filhas
> >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
> >> e índices que uma chave natural economiza.
> >
> > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível
> mais
> > baixo da contabilidade (rateio de centro de custo) a chave primária da
> > tabela tipo por volta de 15 campos!!!
>
> Para isso que se criam chaves artificiais, que nem precisam ser
> primárias.  Na verdade, o ideal é que não sejam, para que o modelo
> fique mais claro e para que nunca se esqueça de definir ao menos uma
> chave natural.
>
>
> > Imagine como era trabalhar com uma modelagem desta!
>
> Com um ferramental adequado, não devia ser problema algum.  Eu fazia
> isso com COPYs Cobol, sem dramas.  Vi muito javeiro reclamando, e
> questionava-os por que o Java seria tão inferior ao Cobol para fazer
> algo tão básico.
>
> O que tem de ver é se essa propagação de chaves compostas não seria um
> problema de armazenamento ou consumo de memória.  Poderia em tese ser,
> e geralmente não é, até por evitar criar campos e índices adicionais
> para as chaves artificiais.
>
> Agora, se o ferramental é ruim ou mal usado… infelizmente, uma
> situação comum.  Espere problemas com usuários mais ingênuos de ORM,
> por exemplo.
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 11:05 GMT-03:00 Gustavo :
>
> mais um detalhe, com a chave composta
> evita um monte de triggers para ajuste de algumas informações também,
> erros de programação
> e menos manutenção

Vero.

Só um detalhe: isso não é exatamente função de chaves compostas, mas
de chaves naturais (que podem precisar ser compostas).

Na verdade, o pior problema em termos de modelagem é colocar chaves
artificiais e não colocar as chaves naturais correspondentes.  Qual é
primária ou não, não tem a mesma importância para para consistência
(integridade)  — embora seja importante para evitar junções, por
exemplo.


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

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
> chave com, digamos, quatro ou cinco atributos por tabelas filhas
> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
> e índices que uma chave natural economiza.
>

Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível mais
baixo da contabilidade (rateio de centro de custo) a chave primária da
tabela tipo por volta de 15 campos!!!

Imagine como era trabalhar com uma modelagem desta!

Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Gustavo 
mais um detalhe, com a chave composta
evita um monte de triggers para ajuste de algumas informações também,
erros de programação
e menos manutenção
ᐧ

Em 25 de agosto de 2016 10:56, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-25 10:49 GMT-03:00 Gustavo :
> >
> > Razão, seria as lendas urbanas que sempre eu via sobre isso...
>
> Boa definição.
>
>
> > agora você me dizendo que é uma otima ideia  ja até pensei em uma chave
> primaria com 3 campos
>
> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
> chave com, digamos, quatro ou cinco atributos por tabelas filhas
> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
> e índices que uma chave natural economiza.
>
>
> > vamos analisar da seguinte maneira. se não fosse uma boa prática não
> teria essa opção para ser usada no banco de dados...
>
> Infelizmente essa lógica nem sempre se aplica.  Por exemplo, herança
> geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo
> físico, foi útil para gambiarrar particionamento de tabelas.
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 10:49 GMT-03:00 Gustavo :
>
> Razão, seria as lendas urbanas que sempre eu via sobre isso...

Boa definição.


> agora você me dizendo que é uma otima ideia  ja até pensei em uma chave 
> primaria com 3 campos

Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
chave com, digamos, quatro ou cinco atributos por tabelas filhas
(chaves estrangeiras), mas deixa-se de levar em conta todas as junções
e índices que uma chave natural economiza.


> vamos analisar da seguinte maneira. se não fosse uma boa prática não teria 
> essa opção para ser usada no banco de dados...

Infelizmente essa lógica nem sempre se aplica.  Por exemplo, herança
geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo
físico, foi útil para gambiarrar particionamento de tabelas.


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

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Gustavo 
Razão, seria as lendas urbanas que sempre eu via sobre isso...
agora você me dizendo que é uma *otima* ideia   ja até pensei em uma
chave primaria com 3 campos

vamos analisar da seguinte maneira. se não fosse uma boa prática não teria
essa opção para ser usada no banco de dados...
ᐧ

Em 25 de agosto de 2016 10:30, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-25 10:22 GMT-03:00 Gustavo :
> >
> > eu nunca utilizei uma chave primaria com 2 campos em 12 anos
>
> Alguma razão para isso?
>
>
> > a pergunta é, seria uma boa pratica utilizar chave primaria composta
>
> Ótima!
>
>
> > eu terei problemas com isso ?
>
> Só em situações-limite, muito específicas mesmo.  Ou seja, certeza
> quase absoluta que não.
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 10:22 GMT-03:00 Gustavo :
>
> eu nunca utilizei uma chave primaria com 2 campos em 12 anos

Alguma razão para isso?


> a pergunta é, seria uma boa pratica utilizar chave primaria composta

Ótima!


> eu terei problemas com isso ?

Só em situações-limite, muito específicas mesmo.  Ou seja, certeza
quase absoluta que não.


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