Em 28 de abril de 2015 17:30, Matheus Saraiva <matheus.sara...@gmail.com> 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:leand...@jabber.org +55 (61) 9302 2691 ICQ/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
