> E se o servidor for modesto? Se o espaço de armazenamento for um > requisito crítico?
>Tire a artificial, se for o caso. Mas lembre-se da máxima: otimização >precoce é raiz de toda sorte de males. Quanto ao desempenho de JOINS realmente nuca testei, mas acho que quanto a espaço em disco ao usar chaves naturais compostas para relacionamento é algo inevitavelmente mais custoso, já que teria-se que replicar os mesmo campos que compõe a chave primária na tabela que se relacionaria com ela. Acho que para esse caso, eu usaria chaves artificiais para o relacionamento e criaria UNIQUEs para garantir a unicidade. Em 28 de abril de 2015 19:44, Guimarães Faria Corcete DUTRA, Leandro < [email protected]> escreveu: > Em 28 de abril de 2015 17:30, Matheus Saraiva > <[email protected]> escreveu: > > > > Já vi muita gente criticando as chaves artificiais e aconselhando o uso > > de chaves naturais simples ou mesmo compostas. > > São duas questões separadas. > > Não é possível criticar as chaves artificiais, assim como não é > possível criticar, digamos, o oceano Atlântico. São um fato da vida. > O que se critica é o abuso delas. > > Chaves artificiais foram primeiro imaginadas como um recurso para os > DBAs implementarem por debaixo dos panos, como equivalentes a uma > chave natural composta ou, por algum outro motivo, relativamente > ineficiente. Não era para ser visível no modelo lógico de dados, e > portanto nem aplicações, nem usuários a veriam. > > Entretanto, infelizmente o SQL — ou, pelo menos, suas atuais > implementações — não permite separar direito os modelos lógico e > físico; assim, começou-se a criar chaves artificiais como complementos > visíveis, em vez de como implementações invisíveis, de chaves > naturais. Até aí, o pressuposto seria que, além de uma chave > artificial, sempre haveria ao menos uma chave natural em cada relação > (‘tabela’). > > O problema é que hoje em dia a maior parte dos usuários nem se > preocupa em definir uma chave natural por relação que seja. Isso leva > a vários problemas, dos quais o mais imediato é a possibilidade de > duplicação de dados, e o mais importante é o desconhecimento do > próprio modelo de dados (do qual ao menos uma chave natural por > relação é parte essencial). > > Outra maneira de ver a coisa: uma chave artificial não é uma chave de > verdade, a menos que corresponda a uma chave natural declarada, > implementada e operante, uma vez que não cumpre a função básica de uma > chave, que é garantir unicidade. Em inglês, isso fica claro no nome > /surrogate/, que é um substituto, um procurador; será que seria o caso > de pararmos de as chamarmos de ‘artificiais’ e usarmos algo mais > próximo de uma tradução de /surrogate/, como ‘substituto’ ou > ‘complementar’? Não sei qual seria uma tradução que restringisse a > interpretação à original; talvez ‘por procuração’? > > > > Uma chave natural composta de (email, cnpj, nome). Isso não causaria > > redundâncias de dados, aumentaria o consumo de espaço em disco e > > prejudicaria o desempenho? > > Não, isso evita duplicidade e é essencial. A chave artificial é que, > por definição, é redundante (desnecessária); e a falta de declaração > duma chave natural leva a validações em aplicação, que geralmente são > piores que as feitas pelo SGBD. > > > > Visto que é mais leve e performático gravar, > > duplicar e fazer transações com um INTEGER do que em um conjunto de três > > VARCHAR? > > Não necessariamente. Você já conduziu os testes comparando? Já > verificou o contraste entre usar uma chave natural e a validação em > aplicação? Já verificou quantas junções o uso de chaves naturais > evita? E os custos decorrentes de manutenção necessária pela má > compreensão do modelo ao longo da vida útil da base? > > Geralmente, a disciplina de definir chaves naturais em cada relação > ajuda a normalizar a base, tornando o sistema como um todo mais leve, > mais lógico e mais robusto. Mesmo que num caso ou noutro tenha de se > complementar as chaves naturais com uma ou outra artificial. > > > > E se o servidor for modesto? Se o espaço de armazenamento for um > > requisito crítico? > > Tire a artificial, se for o caso. Mas lembre-se da máxima: otimização > precoce é raiz de toda sorte de males. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:[email protected] > +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:[email protected] > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
