Re: [pgbr-geral] Definição

[Marcio A. Sepp]

> Em 24 de nov de 2017, às 21:06, Leandro Guimarães Faria Corcete DUTRA 
> <l...@dutras.org> escreveu:
> 
>> Le ven. 24 nov. 2017 à 19:09, Marcio A. Sepp <mar...@zyontecnologia.com.br> 
>> a écrit :
>> o campo c2t2 ele eh a chave natural para a tabela. Soh pensei em talvez 
>> utilizar os dois campos na chave por motivo de acoplamento para as tabelas 
>> que se referenciarem a t2
> 
> Então realmente está errado.  Uma chave natural deve ser a primária, 
> geralmente; de qualquer maneira, declarar uma chave que inclua a primária e 
> mais atributos é um erro grave.  Basta declarar o outro atributo como chave 
> estrangeira para a outra relação (tabela).
> 
> 
Muito obrigado.


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

Re: [pgbr-geral] Definição

[Marcio A. Sepp]

> Em 24 de nov de 2017, às 17:13, Leandro Guimarães Faria Corcete DUTRA 
>  escreveu:
> 
>> Le vendredi 24 novembre 2017 à 16:46 -0200, Márcio A. Sepp a écrit :
>> 
>> create table t2
>> ( c1t1 integer,
>>  c2t2 integer,
>>  c3t2 integer,
>> primary key (c1t1, c2t2),
>> foreign key (c1t1) references t1 (c1t1),
>> unique (c2t2));
> 
> Chave primária (PRIMARY KEY) e alternativa (UNIQUE) são conceitualmente
> equivalentes — ambas são chaves candidatas.
> 
>Assim, pergunto-me se faz sentido que uma chave composta também
> contenha uma outra chave; em outros termos, que uma chave composta seja
> constituída de uma chave (c2t2) e mais outro atributo (c1t1).
> 
>Como teu modelo está com nomes opacos (não significativos) e
> não está comentado, não consigo entendê-lo.
> 
> 
Desculpe, eu omiti uma informação importante. No caso o campo c2t2 ele eh a 
chave natural para a tabela. Soh pensei em talvez utilizar os dois campos na 
chave por motivo de acoplamento para as tabelas que se referenciarem a t2

___
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 definição

[Marcio A. Sepp]

Peço desculpas, mas não consegui organizar o e-mail direito.

> Em 24 de jan de 2017, às 19:07, Leandro Guimaraens Faria Corcete DUTRA 
>  escreveu:
> 
> Le mar. 24 janv. 2017 à 18:00, Márcio A. Sepp  
> a écrit :
>>> > O problema disso é que se eu criar o campo como sendo integer, lá
>>> > pelas tantas corro o risco de dar violação de PK.
>>> Boiei.  Como assim?
>> '0012345'::integer = 12345
> 
> O que voce quer dizer e' que armazena sequencias de caracteres contendo 
> apenas digitos como inteiros?  Se tua regra de negocio diferencia zeros 'a 
> esquerda, pode ser problema.  Mas, no caso, creio que o correto seria dizer 
> que e' caracter com uma restricao de integridade de conferencia, talvez com 
> uma expressao regular [0-9]* ou algo assim (estou enferrujado com as 
> expressoes regulares, e muito mais coisas alias).  Se e' que entendi direito.
> 
> 
>>> > As soluções possíveis seriam criar o campo como varchar(7) ou colocar
>>> > um segundo campo na chave para identificar a informação.
>>> Acho que veio algo truncado.  Nao me fez sentido.
>> Ficou estranho, mas vc já respondeu acima. Vou dividir a informação em 02 
>> campos integer menores (smallint numa dessas).
>> Obrigado.
>> Dúvida resolvida.
> 
> Mas esclareca-nos, por favor.
> 

O caso eh que tem um cadastro de itens onde o código do item pode vir com 5 ou 
com 7 dígitos. Quando o item eh de um determinado importador ele tem 5 dígitos 
e qdo eh do mercado interno ele tem 7. 
Exemplo d código d produto com 7 dígitos: 0012345.
Exemplo d código d produto com 5 dígitos: 01234

O que eh melhor (ou mais correto a fazer neste caso):
1) crio um campo para identificar a origem (importador "xxx" ou mercado 
interno) e junto esse campo na chave. A chave seria composta pelo campo origem 
e o campo código do item (neste caso integer);
2) crio o campo código como sendo varchar(7);


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

Re: [pgbr-geral] RES: Binary column - Setando null

[Marcio A. Sepp]

> 
> Não vai demorar.. pois não será feito tudo de uma vez.. será feito 1000 rows 
> por vez, por exemplo.
>  
>> Apenas por curiosidade, dropar o campo levaria mais tempo?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Replicação horizontal de tabelas

[Marcio A. Sepp]

Boa noite (madrugada),


Conforme sugerido num email anterior, estou abrindo este tópico para deixar a 
lista mais organizada.
A pergunta eh simples: como vcs tratam tabelas de movimentação que contém 
muitos registros e que são referenciadas por outros objetos (fks)?

Fatos a serem considerados:
- essas tabelas possuem dados históricos, que são acessados raramente é são 
somente leitura;
- essas mesmas tabelas são muito acessadas para gravação e leituras de dados 
recentemente inseridos, logo deixando elas com menos registros as consultas 
seriam mais rápidas?!?!?!
- a herança não atende pois não lida com chaves estrangeiras;


Obrigado a tds,

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

Re: [pgbr-geral] RES: Replicação e ambiente complexo

[Marcio A. Sepp]

Enviado do meu iPad

 Em 10/12/2014, às 19:55, Flavio Henrique Araque Gurgel fha...@gmail.com 
 escreveu:
 
  o assunto está fora da pergunta original sobre replicação.
 

Concordo. Abri outra thread.
 Sugiro aos colegas que estão fazendo perguntas abertas (como eu faria se 
 houvesse um ambiente A que precisa fazer B se o PostgreSQL deveria fazer C) 
 que :
 
 - lessem um pouco documentação e livros largamente disponíveis, muitos de 
 graça
 - brincarem um pouco, o PostgreSQL tem a qualidade extra de ser grátis e 
 facilmente instalável
 - fizessem perguntas um pouco mais direcionadas a problemas reais e 
 específicos.
 
Na verdade estou fzndo com um estudo e talvez tenho de reestruturar meu banco 
para que ele satisfaça minha necessidade. O caso eh muito semelhante ao do 
banco usado como exemplo aqui neste email.
 Sim, o Banco do Brasil usa PostgreSQL. Não, eu não sou DBA lá, mas ele lê o 
 que estamos discutindo aqui e dá seus pitacos de tempos em tempos :) ele 
 contou sua história num evento recente.
 
Alguns anos atrás era escritório fixo da IBM lá. Que bom que o DB2 deu lugar ao 
postgre. Se acaso tiver um link desse evento eu tenho interesse.

 []s
 Flavio Gurgel
 
 ___
 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