2011/5/11 Adorilson Bezerra de Araujo <[email protected]>: > > Generalizando esse pergunta, ela deveria ser algo como: > Qual campo devo usar para chave primaria?
O que for melhor para a situação específica. O que depende não só do modelo como do SGBD. Quanto melhor o SGBD, mais haverá situações onde se possa — e deva — usar as chaves naturais. > Um campo natural (das regras de > negócios) ou um campo criado especificamente para isso? A chave artificial é sempre redundante. Se o SQL fosse relacional, e se os SGBDs fossem conformes ao modelo relacional, poderíamos limitar as chaves artificiais ao conceito original de sua concepção: um índice único, visível apenas no modelo físico, não no lógico — ou seja, para DBAs, SysAdmins e programadores de sistema, não para ADs, programadores de aplicativo ou usuários —, criado apenas quando houver necessidade por criticidade de desempenho ou escalabilidade. > Particularmente, eu nunca uso chaves naturais como chaves primárias, cedo ou > tarde você terá problemas com isso. Sempre teremos problemas, nossos sistemas foram feitos para resolver problemas. De maneira geral, chaves artificiais, num SGBD de qualidade (como o PostgreSQL) resolvem mais problemas que criam numa minoria das situações. Entretanto, são problemas relativamente pouco visíveis para a mentalidade dos programadores, que as costumam criar. Se as bases fossem modeladas por ADs ou usuários com conhecimento de causa, provavelmente essa impressão seria inversa. > Há quem discorde e não veja problemas nisso. Isso é óbvio. A questão não é nem quem discorde: é porque discorda. > Existe um artigo bastante interessante sobre o tema[0], mostrando pros e > contras de uma outra decisão. > [0] http://www.agiledata.org/essays/keys.html Esse artigo é autocontraditório. É como se o autor tivesse copiado as definições do começo de alguma obra de referência, mas não tivesse entendido seu significado e implicações lógicas. O que me saltou aos olhos — não que eu tenha tido pachorra de ler tudo, mas não preciso comer um ovo para saber que está podre — é que ele começa dando as definições de chaves simples e compostas, naturais e artificiais, e primárias e candidatas, mas logo depois demonstra ignorar (conscientemente ou não) que essas três classificações são ortogonais, ou seja, independentes entre si: ele condena chaves ‘inteligentes’, sem perceber (ou esclarecer) que não há chaves ‘inteligentes’, apenas chaves definidas sobre atributos não‐atômicos; em outras palavras, que o problema das chaves ‘inteligentes’ é um falso problema, porque o problema real é anterior, da definição dos tipos abstratos que, necessariamente, subjacem um modelo lógico. Os artigos do Josh Berkus, do Chris(topher) J Date, do Fabian Pascal, do Hugh Darwen e do David McGoveran evitam esses erros fundamentais. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:[email protected] +55 (11) 9406 7191 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
