2009/12/29 Mozart Hasse <[email protected]>:
>> Na verdade, chave serial é contradição em termos, porque se é serial
>> não vai garantir unicidade.
>
> Sim, mas para achar o registro e fazer JOINs, é o que há em termos de
> praticidade e desempenho
Depende, como sempre.
> especialmente se você quiser usar a chave para
> identificar alterações concorrentes sobre o mesmo registro
Nível de isolamento serializável, e de quebra a aplicação fica mais
robusta.
Agora me dei conta… será que teus problemas recorrentes de desempenho
não são por controle de transações na aplicação?
> se precisar alterar a chave natural de um registro numa tabela com um
> monte de tabelas filhas.
ON UPDATE CASCADE
> A melhoria é grande demais para ser ignorada, pois
> quase todos os índices ficarão menores
Nana-nina-não.
Ou melhor, depende. Tabela mãe pequena e pouco usada com tabelas
filhas grandes, pode ser, se não forçar junções demais.
Mas sempre haverá um índice a mais, tanto em disco quanto em memória,
ocupando também cache e exigindo atualizações.
> e com distribuição estatística mais
> evidente (do ponto de vista do banco de dados) usando uma PK numérica
> de um só campo.
Não.
> Além do mais, ninguém falou em não declarar chaves alternativas para
> evitar duplicidades.
Mas é o que costuma acabar acontecendo.
> Tudo bem, concordo que conceitualmente é uma atrocidade, mas estamos
> falando de modelo físico, não do modelo lógico...
Esse é o problema do SQL, falta de independência de dados.
Mesmo em SQL, os efeitos técnicos e culturais das chaves artificiais e
da normalização deficiente, que costumam andar juntos, geralmente acaba
prejudicando não só desempenho quanto robustez.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 9406 7191 gTalk: xmpp:[email protected]
+55 (11) 3854 7191 ICQ: aim:GoIM?screenname=61287803
+55 (11) 5546 8716 msnim:[email protected]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
