De alguma maneira não li esta mensagem de ontem.
Em Qui, 2007-06-21 às 15:37 -0300, Wallace Reis escreveu:
> On 6/21/07, Leandro Guimaraes Faria Corcete DUTRA <[EMAIL PROTECTED]> wrote:
> > Por que vai?
> Degradação de performance.
> No meu caso com cerca de 19 milhões de registros em uma única tabela
> ajuda, e muito.
Só se as grandes tabelas forem filhas de tabelas com chaves primárias
compostas. Caso contrário, você ganha por não ter de acrescentar mais
um atributo.
> Ao meu ver, o ideal é usar uma chave natural *não
> inteligente* como chave primária, quando não puder ae cabe o uso de
> chave artificial.
O ideal é usar qualquer chave natural. Esse conceito de ’chave
inteligente’ é bastante subjetivo.
> Você vai ter que alterar o check constraint para a nova lógica e
> executar uma operação de update e com o "on cascade", a depender do
> seu bd, em várias tabelas que contém milhões de registros. Se você
> pensar em um banco de currículos ou um forúm que são ambientes com
> pequeno volume de dados, neste caso você tem razão.
Rapaz, não vejo como o CPF ou o RG vão mudar tão drasticamente. Como
falei, esse conceito de chave inteligente não é muito útil…
principalmente se uma chave externa é considerada inteligente!
> A ironia que o Gilberto fez foi exatemente a msm que uma pessoa fez na
> usenet e a resposta do JOE CELKO foi:
> "Dr. Codd would be VERY surprised to find out that his papers had
> no mention of primary keys in them.";
> claro que a cláusula SQL PRIMARY KEY tem adições de propriedades ao
> conceito de chave primária criado por Dr. Codd.
Na verdade tem de haver chave(s) natural(is). A questão de qual será a
primária é completamente arbitrária. No SQL é obrigatório, no modelo
relacional não.
> p.s.: acredito que o assunto ta fugindo do inicial da thread. acho até
> melhor continuarmos a conversar em privado diretamente no email
> pessoal do que pela lista, pois vc tem colocado muita emoção e se
> exaltado em suas mensagens.
É uma lista de discussões, certo?
Eu me exalto pela verdade. Não suporto o tanto de confusão que se tem
gerado na área, atrapalhando imenso o progresso.
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation._______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
