Re: [pgbr-geral] Vacuum e Vacuum Full

2017-09-25 Por tôpico Fernando Franquini 'capin' 
Em 22 de setembro de 2017 22:20, Euler Taveira <eu...@timbira.com.br>
escreveu:

> Em 22 de setembro de 2017 16:36, Fernando Franquini 'capin' <
> fernando.franqu...@gmail.com> escreveu:
>
>>
>> tenho um ambiente com Postgres 9.3.19.
>> Linux Centos 6 Kernel 2.6.32-504.12.2.el6.x86_64 (sei que é velho! eheh)
>>
>> Se ambos estiverem com correções aplicadas, não vejo problema (pelo menos
> até serem descontinuados). Daqui a 1 ano a versão 9.3 será descontinuada; é
> tempo suficiente para você planejar a migração para uma versão recente.
>

Já está no backlog essa evolução! :)


>
>
>> O problema que não tenho entendido é que mesmo após executar os comandos
>> de Vacuum ou Vacuum full nessas tabelas, os valores ainda permanecem
>> inalterados.
>>
>> O que você precisa entender é que as colunas n_tup_* são incrementais (a
> não ser que você faça um reset nas estatísticas) e a coluna n_dead_tup é
> alterada com a execução do VACUUM (valor vai para zero). Apesar de n_tup_*
> ser incremental, há uma outra variável (n_mod_since_analyze -- valor só foi
> exposto a partir da 9.4) que vai guardando o quanto foi alterado para usar
> como base para disparar o autoanalyze (valor vai a zero depois da
> execução). O autovacuum é disparado comparando com n_dead_tup.
>

> Se você estiver preocupado com espaço deixado pelo inchaço e quer
> controlar isso melhor, eu sugiro que você agende VACUUM manual ao longo do
> dia (em um horário conveniente) ou diminua os parâmetros do autovacuum
> (somente se o quantitativo de tabelas que crescem for pequeno. A ideia é
> não prejudicar o andamento da operação ao longo do dia).
>


Sim, a minha preocupação está voltada mesmo a degradação de performance,
espaço em disco também, mas vejo que se não entrar com o VACUUM (conforme
sua sugestão que já tenho feito) o sistema começa a ficar um pouco lento.

Obrigado pelas informações.
Vejo que realmente os meus cenários que envolvem muita carga e exclusão de
dados está me deixando sem o restante dos cabelos!
hehehe

Abraços e obrigado novamente.

-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
<http://franquini.wordpress.com/>
http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Vacuum e Vacuum Full

2017-09-22 Por tôpico Fernando Franquini 'capin' 
Boa tarde,

tenho um ambiente com Postgres 9.3.19.
Linux Centos 6 Kernel 2.6.32-504.12.2.el6.x86_64 (sei que é velho! eheh)

Tenho várias tabelas que são removidos e inseridos vários dados durante o
dia todo, tempo todo.

Preciso as vezes executar vacuum e vacuum full na mão, vou colocar um print
para terem ideia dos volumes de dados:
[image: Imagem inline 1]

Os meus parâmetros do Autovacuum estão no padrão:

O Autovacuum quase não tem executado, logo, os parâmetros não estão
atendendo, em conversa com o Fabrizio alterei alguns parâmetros direto nas
tabelas.

O problema que não tenho entendido é que mesmo após executar os comandos de
Vacuum ou Vacuum full nessas tabelas, os valores ainda permanecem
inalterados.

Alguém saberia me dizer mais alguma coisa?

Grato pela atenção.
-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil

http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

2016-12-05 Por tôpico Fernando Franquini 'capin' 
Em 29 de novembro de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-11-29 8:36 GMT-02:00 Fernando Franquini 'capin'
> <fernando.franqu...@gmail.com>:
> >
> > talvez o cenário, são milhares de deletes e inserts diários, pode ser por
> > isso.
>
> Nah, isso aí não é nada.  A menos que sejam INSERTs & DELETEs
> extraordinariamente pesados, acontecendo muito concentradamente, e em
> momento crítico.  Probablilidade praticamente zero.
>

Certo.


>
>
> > E sim, vinham de uma versão antiguíssima (8.4) do PostgreSQL.
>
> Antiga, mas quando VACCUUM já não devia ser mais problema.  O mais
> provável é que na época leram coisas mais antigas ainda, e (como é
> extremamente comum) aplicaram sem fundamento.
>

Blz.


>
>
> > Mas sim, farei meu teste, só tenho que planejar bem, pois será direto em
> > produção.
>
> Não tens um paralelo?
>
>  Não.


-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
<http://franquini.wordpress.com/>
http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

2016-12-05 Por tôpico Fernando Franquini 'capin' 
Em 29 de novembro de 2016 12:11, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 28-11-2016 09:16, Fernando Franquini 'capin' wrote:
> >
> > O autovacuum deveria fazer isso pra você. VACUUM FULL é uma operação
> > custosa para tabelas grandes e a tabela fica bloqueada durante toda
> > a execução.
> > Seu autovacuum está ligado ?
> > Faça :
> > SHOW autovaccum;
> > Pode ser que seu dba anterior tenha deixado desligado por algum
> motivo.
> >
> >
> > Sim, está desligado por opção, pois chegaram a conclusão que o
> > AUTOVACUUM durante o dia atrapalha (devido o tamanho das tabelas - Mas
> > ainda quero realizar uma alteração a acompanhar isso um dia), por isso é
> > feito VACUUM em algumas tabelas principais durante a noite (porque é
> > mais rápido) e VACUUM FULL no final de semana, sim, temos essa janela.
> >
>
> Esse é um equivoco comum... desligar o autovacuum é, na maioria dos
> cenários, pior do que manter ligado. Dê uma lida nesse post da CitusData
> que nosso colega Sebastian gentilmente traduziu para pt-br [1].
>
> Vc precisa entender que tabelas que geram muitas tuplas mortas (por
> DELETE/UPDATE ou INSERT cancelado) o autovacuum deve ser mais agressivo,
> ou seja, executar com mais frequencia... a idéia é que ele fique "sempre
> rodando rapidamente" na tabela... e não o contrário.
>

Fabrizio, obrigado. Foi exatamente por ler ele que comecei a olhar mais a
fundo.
Abraços.


>
>
> >
> > <..corte..>
> >
> > Isso não é um problema, é apenas uma estatística sobre como seu
> > banco usa uma tabela.
> >
> >
> > Opa, blz então. Se fica somente na estatística, pode prejudicar a
> > utilização dos índices, certo?
> >
>
> Essa estatística que o Flávio mencionou não influencia diretamente nos
> planos de execução, se esse é seu receio. Que usa essa informação é o
> próprio "launcher" do autovacuum, mas também pode ser usada por sua
> ferramenta de monitoramento preferida para acompanhar os picos de mais
> "lixo" deixado pra trás em determinados objetos... uso muito essa
> informação para auxiliar no tuning do autovacuum.
>
> Att,
>
>
> [1] http://swebber.me/blog/2016/11/14/autovacuum-nao-e-o-inimigo/
>
> --
>Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
<http://franquini.wordpress.com/>
http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

2016-11-29 Por tôpico Fernando Franquini 'capin' 
Dutra,

talvez o cenário, são milhares de deletes e inserts diários, pode ser por
isso. E sim, vinham de uma versão antiguíssima (8.4) do PostgreSQL.

Eu vou estudar a documentação e conhecer melhor o ambiente/problema para
poder tirar as minhas conclusões, claro, com algumas ajudas! ehehhe

Mas sim, farei meu teste, só tenho que planejar bem, pois será direto em
produção.

Obrigado.
Capin

Em 28 de novembro de 2016 15:12, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-11-28 9:16 GMT-02:00 Fernando Franquini 'capin'
> <fernando.franqu...@gmail.com>:
> >
> > Sim, está desligado por opção, pois chegaram a conclusão que o AUTOVACUUM
> > durante o dia atrapalha (devido o tamanho das tabelas - Mas ainda quero
> > realizar uma alteração a acompanhar isso um dia), por isso é feito
> VACUUM em
> > algumas tabelas principais durante a noite (porque é mais rápido) e
> VACUUM
> > FULL no final de semana, sim, temos essa janela.
>
> Geralmente esse tipo de conclusão se baseia nalguma observação falha,
> por exemplo, de versão muito antiga, talvez bugada, ou de diagnóstico
> incorreto ou incompleto de um problema.  Faça teu teste.
>
>
> --
> 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




-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
<http://franquini.wordpress.com/>
http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

2016-11-28 Por tôpico Fernando Franquini 'capin' 
Flávio, bom dia e obrigado pela atenção.


Em 24 de novembro de 2016 11:30, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
>
> Em qui, 24 de nov de 2016 às 13:34, Fernando Franquini 'capin' <
> fernando.franqu...@gmail.com> escreveu:
>
>> Bom dia,
>>
>> sou novo como DBA PostgreSQL, então desculpe a ignorância.
>>
>
> Não há problemas em ser novato aqui. Bem vindo.
> Basta seguir as regras da lista.
>

:D


>
>> Utilizamos a versão 9.4, temos algumas tabelas que sofrem DELETE e INSERT
>> o tempo todo e algumas muitos UPDATE.
>>
>> Tenho uma query que foi passada pelo antigo DBA para analise de linhas
>> mortas e deletadas:
>> SELECT schemaname, relname, n_live_tup, n_tup_del, n_dead_tup, CASE WHEN
>>   last_analyze > last_autoanalyze THEN last_analyze ELSE last_autoanalyze
>> --
>> end   AS data_analyze, CASE WHEN last_vacuum > last_autovacuum THEN
>>   last_vacuum ELSE last_autovacuum --
>>end
>>AS data_vacuum, round ((n_dead_tup / n_live_tup::NUMERIC) * 100,
>> 2) AS
>>  perc_dead, round ((n_tup_del / n_live_tup::NUMERIC) * 100, 2) AS
>>  perc_del
>> FROM pg_stat_user_tables
>> WHERE n_live_tup > 100
>> ORDER BY perc_del DESC;
>>
>> Baseado nessa consulta eu tenho alguns números elevados nas colunas
>> *perc_dead* e *perc_del*, porém ao realizar manutenções com VACUUM FULL
>> eu resolvo os problemas das linhas mortas.
>>
>
> O autovacuum deveria fazer isso pra você. VACUUM FULL é uma operação
> custosa para tabelas grandes e a tabela fica bloqueada durante toda a
> execução.
> Seu autovacuum está ligado ?
> Faça :
> SHOW autovaccum;
> Pode ser que seu dba anterior tenha deixado desligado por algum motivo.
>

Sim, está desligado por opção, pois chegaram a conclusão que o AUTOVACUUM
durante o dia atrapalha (devido o tamanho das tabelas - Mas ainda quero
realizar uma alteração a acompanhar isso um dia), por isso é feito VACUUM
em algumas tabelas principais durante a noite (porque é mais rápido) e
VACUUM FULL no final de semana, sim, temos essa janela.

Dúvidas:
>>
>> - Qual o percentual considerado algo para as linhas excluídas?
>>
>
> Não existe. A quantidade de linhas excluídas só depende de quanto DELETE
> foi feito numa tabela. Logo, cada aplicação faz o que precisa fazer.
>

Obrigado.


>
>
>> - Qual o percentual considerado algo para as linhas mortas?
>>
>
> Na configuração padrão do autovacuum, ele vai entrar quando esse
> percentual atinge 20%.
> Essa configuração pode ser alterada. Faça:
> SHOW autovacuum_vacuum_scale_factor;
> Logo, no seu caso, se o valor está abaixo de 20%, você pode simplesmente
> esperar o autovacuum entrar sozinho.
> Se o valor está acima, veja a minha pergunta mais acima se seu autovacuum
> está ligado.
> Se você quiser que isso seja controlado com mais frequência, reduza o
> valor na configuração autovacuum_vacuum_scale_factor.
>

Blz, isso li na documentação, vi que posso alterar por tabela caso
necessário, caso 20% seja muita informação alterada. Mas de qualquer forma
obrigado :)


> - Como posso resolver problema das linhas excluídas?
>>
>
> Isso não é um problema, é apenas uma estatística sobre como seu banco usa
> uma tabela.
>

Opa, blz então. Se fica somente na estatística, pode prejudicar a
utilização dos índices, certo?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete

2016-11-24 Por tôpico Fernando Franquini 'capin' 
Bom dia,

sou novo como DBA PostgreSQL, então desculpe a ignorância.

Utilizamos a versão 9.4, temos algumas tabelas que sofrem DELETE e INSERT o
tempo todo e algumas muitos UPDATE.

Tenho uma query que foi passada pelo antigo DBA para analise de linhas
mortas e deletadas:
SELECT schemaname, relname, n_live_tup, n_tup_del, n_dead_tup, CASE WHEN
  last_analyze > last_autoanalyze THEN last_analyze ELSE last_autoanalyze --
end   AS data_analyze, CASE WHEN last_vacuum > last_autovacuum THEN
  last_vacuum ELSE last_autovacuum --
   end
   AS data_vacuum, round ((n_dead_tup / n_live_tup::NUMERIC) * 100, 2)
AS
 perc_dead, round ((n_tup_del / n_live_tup::NUMERIC) * 100, 2) AS
 perc_del
FROM pg_stat_user_tables
WHERE n_live_tup > 100
ORDER BY perc_del DESC;

Baseado nessa consulta eu tenho alguns números elevados nas colunas
*perc_dead* e *perc_del*, porém ao realizar manutenções com VACUUM FULL eu
resolvo os problemas das linhas mortas.

Dúvidas:

- Qual o percentual considerado algo para as linhas excluídas?
- Qual o percentual considerado algo para as linhas mortas?
- Como posso resolver problema das linhas excluídas?

Agradeço a atenção de todos.

-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil

http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Criar ou não Indices para Contraints

2016-10-13 Por tôpico Fernando Franquini 'capin' 
Euler,

Eu trabalhei bastante com Oracle e SQL Server, posso afirmar que faziam
diferença e concordo com os pontos (i) e (ii).

Porém em relação a junção fiquei em dúvida no item (iii):

Se a PK da tabela A é FK na tabela B, ao realizar a junção de A com B e
usar a coluna FK vai usar o indice da PK na A e na B nada??

Obrigado pelas colocações.
Abraços.

2016-10-13 11:16 GMT-03:00 Euler Taveira <eu...@timbira.com.br>:

> On 13-10-2016 08:37, Fernando Franquini 'capin' wrote:
> > Mas em princípio ele deve fazer mais bem que mal, porque? Porque toda
> > junção com as chaves (FKs) que forem realizadas irão utilizar esse
> índice.
> >
> Isso pode ser verdade em outros bancos (que criam índice para cada FK);
> no postgres isso não é. É uma prática comum (criar esses índices) mas eu
> particularmente não recomendo porque (i) ocupa espaço, (ii) torna
> operações de INSERT, UPDATE e DELETE lentas (porque é necessário manter
> os índices atualizados) e (iii) junções vão usar o índice da chave
> primária e não o índice da FK. Quando esses índices são úteis? Em
> consultas que não fazem a junção com a tabela da chave primária e a
> cláusula WHERE inclui o campo da FK (e os valores utilizados são
> seletivos).
>
> Nos diversos modelos que trabalhei atrevo a dizer que menos de 2% das
> consultas vão se beneficiar de um índice em um campo que é FK. Portanto,
> eu prefiro ir criando esses índices em FK sob demanda. Em modelos
> consolidados, faz-se uma análise de todas as consultas e os planos de
> execução vão dizer se o índice na FK é benéfico ou não.
>
> Em modelos migrados de outros SGBDs, após uma análise de uso, observa-se
> que a maioria dos índices candidatos a remoção são em FK.
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
<http://franquini.wordpress.com/>
http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Criar ou não Indices para Contraints

2016-10-13 Por tôpico Fernando Franquini 'capin' 
Bom dia,
necessário não é, a constraint vai ter a mesma funcionalidade com ou sem.

Mas em princípio ele deve fazer mais bem que mal, porque? Porque toda
junção com as chaves (FKs) que forem realizadas irão utilizar esse índice.

Abraços
capin

2016-10-12 13:31 GMT-03:00 Gustavo :

> Ola senhores
>
> Uma duvida, sobre relacionamentos
>
> Estou utilizando o Postgres 9.6 e utilizando por pg Admin III e o 4
>
> *quando crio um contraints ele gera um indice automaticamente*
>
>
> a duvida seria, é necessário criar um indice para os CAMPOS que pertence a
> um constraints ??
>
> eu nunca crie um indice para essa finalidade..  mais agora fiquei curioso
> para saber se é necessário ou não criar indices para essa finalidade ?
>
> []s
> Gustavo
> ᐧ
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil

http://certificacaobd.com.br/
http://br.linkedin.com/in/capin
___
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 em VARCHAR

2012-02-17 Por tôpico Fernando Franquini 'capin' 
Moisés,

bom dia, mas porque precisa ser login PK?
Porque você não faz o basico: Criar um Codigo como PK e 'colocar' o Codigo
no GRUPO?

No meu ponto de vista tais preparando um *monstrinho*, caso não seja um
TESTE SEU!

Att,
capin

2012/2/17 Moisés P. Sena moisesps...@gmail.com

 Bom dia pessoal!

 Estou modelando um sistema de autenticação de usuarios mas estou na duvida
 (Do ponto de vista do BD, e nao da aplicacao):

 a) Quero colocar o login como PK da tabela usuario como VARCHAR(30)
 b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30)

 O que voces me falam de performance em usar VARCHAR ou BIGINT?

 Existe algum outro campo de texto mais rapido que VARCHAR?

 Abraços,

 --
 Moisés P. Sena
 (Analista e desenvolvedor de sistemas WEB e mobile)
 http://www.moisespsena.com
 http://linux.moisespsena.com

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




-- 
Fernando Franquini - Capin
Graduado Bacharel em Ciencias da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
Contatos: fernando.franqu...@gmail.com / 048.9902.4047
Florianópolis - SC - Brasil
http://franquini.wordpress.com/
http://franquini.wordpress.com/
http://br.linkedin.com/in/capin
http://wf5.com.br/
http://twitter.com/dbacapin https://twitter.com/#!/dbacapin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR

2012-02-17 Por tôpico Fernando Franquini 'capin' 
Leandro,

agora eu consegui entender o seu ponto de vista.

Então em resumo, sempre que eu tiver uma 'Unique' (dentro do meu ponto de
vista onde PK é Código) eu poderia fazer isso que você está explicando e
somente em casos aonde eu não teria um 'CONTROLE' natural eu poderia
utilizar os CÓDIGOS para essas junções, seria isso?

Podemos dizer também que isso seria ideal não somente para PostgreSQL, mas
para a modelagem mesmo de BD podendo aplicar para qualquer banco de dados
relacional?

Obrigado pela atenção.
capin

2012/2/17 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org

 Devolvendo à lista discussão conduzida em privado…


 -- Forwarded message --
 From: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
 Date: 2012/2/17
 Subject: Re: [pgbr-geral] Chave Primaria em VARCHAR
 To: Fernando Franquini 'capin' fernando.franqu...@gmail.com


 2012/2/17 Fernando Franquini 'capin' fernando.franqu...@gmail.com:
 
  Eu usaria da forma onde o Login seria sim uma Chave Natural, mas podendo
 ser
  Unique!

 Sim, mas para quê?


  Logo, preciso de um código para ser a PK e repassar isso as tabelas
  relacionadas.

 Exato, esse código é desncessário.


  Mas como tu diz que isso está errado, eu não vejo dessa forma.



  Eu digo um *monstrinho*, pois se eu tiver um login que é Email como PK,
 me
  parece que se tiver uns 4 ou 5 relacionamentos que você pode colocar no
  modelo (dependendo da solução), acho que pode começar a complicar as
  consultas, não?

 Pelo contrário, evita junções desnecessárias.


  Pois, se eu tiver uma PK  varchar(100) para Email OU uma PK inteiro (ou
  outro menor) para um código, *ACREDITO* que joins com código seja mais
  eficientes, não?

 Não, como o Euler e o Flávio explicaram…  pelo contrário, quando
 precisares do endereço de correio eletrônico, o que é uma situação bem
 comum, com o uso de chaves artificiais como o teu código precisarás de
 junções para recuperá‐lo.
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Fernando Franquini - Capin
Graduado Bacharel em Ciencias da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
Contatos: fernando.franqu...@gmail.com / 048.9902.4047
Florianópolis - SC - Brasil
http://franquini.wordpress.com/
http://franquini.wordpress.com/
http://br.linkedin.com/in/capin
http://wf5.com.br/
http://twitter.com/dbacapin https://twitter.com/#!/dbacapin
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] quero sair da lista

2009-07-01 Por tôpico Fernando Franquini 'capin' 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

acesse e saia.

2009/7/1 Saul Gabeloni saul.gabel...@gmail.com

 quero sair da lista

 obrigado

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




-- 
__
Fernando Franquini - Capin
Bacharel em Ciencias da Computacao - UFSC
Analista de Sistemas / DBA
emails: ferna...@wf5.com.br / fernando.franqu...@gmail.com
Celular: (48) 99024047
Florianópolis - SC - Brasil
www.wf5.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Resultado do PG Con 2007

2007-12-11 Por tôpico Fernando Franquini - capin 
Eles mandaram

segue o link: 
http://www.temporealeventos.com.br/imagens/pgconbrasil/palestras_pgcon.zip


sem mais,
capin


On Dec 11, 2007 9:26 AM, Benedito A. Cruz [EMAIL PROTECTED] wrote:
 Oi Pessoal

Pelo que me lembro, o pessoal da Tempo Real falou que ia mandar as
 apresentações para os participantes.
 Ou será que ouvi demais ? :-)

 []s

   Benê

 PS Eu sou o cara que ficava  ouvindo um ipod nos intervalos.


 Thiago Risso wrote:
  Assim que tiver um local para colocar a apresentação vou disponibilizar. O
  Fábio pediu para mandar para ele que vão colocar no site do
  postgresql.org.br
 
 
  Ok Jota... Obrigado !
 
 


 --
 --

 Benedito A. Cruz
 Centro de Referência em Informação Ambiental - CRIA
 email [EMAIL PROTECTED]
 fone 55 19 3288 0466


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





-- 
__
Fernando Franquini - Capin
Bacharel em Ciencias da Computacao - UFSC
Administrador de Banco de Dados
emails: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Celular: (48) 99024047
Florianópolis - SC - Brasil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Resultado do PG Con 2007

2007-12-11 Por tôpico Fernando Franquini - capin 
Acho que depois dessas descricoes nem preciso fazer meu relato.
eheheheh

parabens, muito bom.

sem mais,
capin

On Dec 11, 2007 10:22 AM, Fabio Telles [EMAIL PROTECTED] wrote:
 Outro relato do pgcon:
 http://desconstruindo.eng.br/?p=15

 []s

 Em 11/12/07, Leandro DUTRA[EMAIL PROTECTED] escreveu:

  2007/12/11, Evandro Ricardo Silvestre [EMAIL PROTECTED]:
  
Leandro DUTRA wrote:
Realmente deve ser dificil de lembrar de alguém lá. Vai uma dica, no 
   sábado
   estava de vermelho. Sou um pouco mais alto que você bem estreito =D.
Conversamos antes da palestra do Euler sobre Sintonia em SQL.
Mas não esquenta a cabeça.
 
  Não vou esquentar, mas de qualquer maneira desculpe… acho que a RAM
  foi apagada com a exaustão de sábado à noite!
 
  --
  +55 (11) 5685 2219   xmpp:[EMAIL PROTECTED]
  +55 (11) 9406 7191  Yahoo!: ymsgr:sendIM?lgcdutra
  +55 (11) 3040 7300  ICQ/AIM: aim:GoIM?screenname=61287803
  MSN: msnim:[EMAIL PROTECTED]
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 


 --
 blog: http://www.midstorm.org/~telles/
 e-mail / jabber: [EMAIL PROTECTED]
 ___

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




-- 
__
Fernando Franquini - Capin
Bacharel em Ciencias da Computacao - UFSC
Analista de Sistemas / DBA
emails: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Celular: (48) 99024047
Florianópolis - SC - Brasil
http://capin.blogspot.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral