none
Chave composta ou Surrogate key RRS feed

  • Discussão Geral

  • Bom tarde pessoal,

    estou tentando decidir se adoto chaves primárias compostas ou Surrogate keys em um projeto de banco de dados.

    O banco de dados deve atender a "n" clientes, ou seja, a "n" aplicações, portanto cada registro de cada tabela deve ter um campo "ID_APLICACAO" para diferenciar os registros de uma aplicação da outra. Caso eu adote por usar chaves primárias compostas o campo "ID_APLICACAO" deve-rá participar da chave primária em todas as tabelas. Isso não me agrada muito e digo porque. Em uma tabela que tenha necessidade de possuir uma chave primária composta de dois campos por exemplo, eu teria que incluir um terceiro (ID_APLICACAO), imagina quando acontecer da tabela necessitar de três campos que participam da chave primária...eu precisaria incluir mais um...

    Caso eu optar pela  modelagem utilizando o conceito de Surrogate key eliminaria essa história de chave primária com "n" campos e facilitaria tecnicamente porém complica a modelagem do banco e na hora de codificar uma query por exemplo (exigiria maior conhecimento do modelo e maior necessidade de "joins" na query).

    O que vocês costumam ou indicam em um projeto como esse?

    sexta-feira, 17 de maio de 2013 16:05

Todas as Respostas

  • Bom tarde pessoal,

    estou tentando decidir se adoto chaves primárias compostas ou Surrogate keys em um projeto de banco de dados.

    O banco de dados deve atender a "n" clientes, ou seja, a "n" aplicações, portanto cada registro de cada tabela deve ter um campo "ID_APLICACAO" para diferenciar os registros de uma aplicação da outra. Caso eu adote por usar chaves primárias compostas o campo "ID_APLICACAO" deve-rá participar da chave primária em todas as tabelas. Isso não me agrada muito e digo porque. Em uma tabela que tenha necessidade de possuir uma chave primária composta de dois campos por exemplo, eu teria que incluir um terceiro (ID_APLICACAO), imagina quando acontecer da tabela necessitar de três campos que participam da chave primária...eu precisaria incluir mais um...

    Caso eu optar pela  modelagem utilizando o conceito de Surrogate key eliminaria essa história de chave primária com "n" campos e facilitaria tecnicamente porém complica a modelagem do banco e na hora de codificar uma query por exemplo (exigiria maior conhecimento do modelo e maior necessidade de "joins" na query).

    O que vocês costumam ou indicam em um projeto como esse?

    nobody?
    segunda-feira, 20 de maio de 2013 19:56
  • Antes de qualquer coisa vale lembrar que este post é de 20 de maio de 2013, já com 2 anos, mas o conhecimento ainda vale, e como alguém pode chegar até aqui, como eu cheguei, vamos conversar... rs.

    Diego, na maior parte do tempo é só uma questão pessoal mesmo, pois a chave artificial (surrogated key) vai exigir menos esforço e reduzir a complexidade das cláusulas where (os predicados da seleção), enquanto as chaves naturais serão sempre mais intuitivas e autoexplicativas, cobrando por isto mais esforço na construção das consultas. Há ainda as restrições de ferramentas de mapeamento Objeto-Relacional, que não impedem de usar chaves naturais compostas complexas, mas aumentam ainda mais o esforço para lidar com elas, principalmente em caso de manutenções manuais.

    No seu caso específico, eu não gostaria de ter que levar uma chave composta em uma estrutura onde três ou quatro níveis de modelagem seriam usados, mas em casos como tabelas de domínio (aka tabelas burras, tabelas fixas, etc), ou nos casos de "folha" (último nível na modelagem) que não vão derivar mais nada, a chave natural ajuda muito na manutenção, enquanto a chave artificial não vai agregar muito valor, por ser um caso simples. É um caso onde a PK da tabela filha é a FK da tabela pai + o campo chave da filha. Aqui a surrogate não se paga, e a natural não exige alto custo de manutenção.

    Resumindo, a decisão pode ser uma opção ou uma imposição de fatores externos, mas não é bom decidir de forma binária: ou usar sempre surrogate ou nunca usar. Talvez seja interessante adotar situações híbridas, dependendo do tamanho do projeto, da equipe, se é open source, etc. Há quem já se decidiu que só usa surrogate, independente de qualquer argumento. Não se preocupe em ter suas decisões julgadas, o que vale é seu resultado, sua satisfação e a produtividade esperada no modelo escolhido. Sempre vai ter alguém para te dizer que podia ser diferente. Até isto podia ser diferente...

    Gosto tanto do assunto sobre modelagem que não resisti em deixar de comentar. Abração e bom trabalho.

    Segue um artigo bem legal a respeito:

    http://litolima.com/2011/03/09/conceito-de-surrogate-key-chaves-substitutas/


    Alexandre Paiva, MCT


    • Editado ASPaiva sábado, 22 de agosto de 2015 14:21 Add a link
    sábado, 22 de agosto de 2015 14:02