2011/5/11 Leandro DUTRA <[email protected]> > 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. >
Não explicitei, mas eu estava mesmo me referindo ao modelo físico e não lógico. E o motivo de não usar é justamente pela questão de escalabilidade/manutenção e afins. 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 > > 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. > Poderia passar o link para esses outros artigos? > > > -- > 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 > -- Adorilson Bezerra <http://twitter.com/ensl_oficial> Atenção: Este e-mail pode conter anexos no formato ODF (Open Document Format)/ABNT (extensões odt, ods, odp, odb, odg). Antes de pedir os anexos em outro formato, você pode instalar gratuita e livremente o BrOffice ( http://www.broffice.org) ou o seguinte Plugin para Microsoft Office ( http://www.sun.com/software/star/odf_plugin/get.jsp).
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
