2011/5/13 Adorilson Bezerra de Araujo <[email protected]>: > >> 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. > > Não explicitei, mas eu estava mesmo me referindo ao modelo físico e não > lógico.
O problema é que o SQL não permite a separação entre o modelo físico e o lógico, e a chave artificial acaba, com o tempo, se tornando uma chave natural redundante. Sem contar, de imediato, que costuma acabar conduzindo à indefinição das chaves naturais, o que obscurece o modelo para todos, gerando más consultas, o que é complicado por forçar muitas junções desnecessárias. Essas coisas só passam porque as pessoas ou não modelam o desempenho nem testam, ou fazem modelagem e testes incorretos, porque parciais. > E o motivo de não usar é justamente pela questão de > escalabilidade/manutenção e afins. Escalabilidade é, normalmente, muito mais questão de aplicação e de configuração do sistema do que de chaves naturais ou artificiais. O caso mais comum é que as chaves naturais sejam mais escaláveis, por evitarem redundância na armazenagem, na memória, nos caches, por evitarem junções e por levarem a melhor entendimento dos dados e, portanto, da aplicação e do código SQL. Os supostos ganhos de manutenção com a adoção de chaves artificiais quase sempre são mais do que negados pelos problemas de modelagem, de programação, entendimento e, finalmente, porque o SQL expõe o modelo físico e as chaves artificiais acabam se tornando mais uma chave natural, mas redundante. > Vejamos no artigo do Josh Berkus[0] (ainda pretendo ler o outro), que no > final das contas, ele acaba utilizando chaves artificiais como PK e como FK, > ficando as chaves naturais como índices para melhor desempenho em > consultas. > [0] http://it.toolbox.com/blogs/database-soup/normalization-performance-and-virtual-private-databases-32525 Acho que faltou reparar no seguinte trecho, para entender o artigo: ‘because the client had built their application using autonumber ids, we couldn't get rid of them, but had to make this compromise:’ >> Os artigos do Josh Berkus, do Chris(topher) J Date, do Fabian Pascal, >> do Hugh Darwen e do David McGoveran evitam esses erros fundamentais. > > Poderia passar o link para esses outros artigos? A maior parte deles eu cadastrei em http://dmoz.org/Computers/Software/Databases/Relational — os do Josh Berkus estão no Database Soup, junto com o artigo que citaste. O mais claro dele, que me lembre, chama-se algo como _Primary Keyvil_. -- 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
