Boa tarde, Pessoalmente, após analisar um pouco mais o assunto, sou a favor de chaves artificiais em muitas tabelas, salvo algumas poucas exceções. Isso não significa que a chave artificial precise estar desprovida de significado. Uma chave primária tem de ser a forma de buscar na tabela usada primariamente e que identifica o registro. Isso significa que criar uma chave artificial numa tabela de pedidos pode ter um sentido, é a identificação de qual o pedido do cliente e quando o mesmo ligar, será solicitada essa chave (número do pedido) para achar o mesmo. Por outro lado, se formos olhar a tabela de clientes, quando um cliente ligar, o que pediremos dele? O CPF/CNPJ, nome, etc., ou o seu número de cadastro (Id)? Nesse caso a chave artificial perde o sentido (meaningless), e precisamos avaliar se haveria razão para usá-la. Antes que mencionem que podemos ter alguma alteração em chaves primárias naturais (mudanças de regras de negócio, por exemplo), essa não seria uma boa justificativa para não usá-las visto a teoria Relacional não proibir alterações de chaves primárias. Por outro lado, no caso de um cliente, qual seria uma boa alternativa? Eu diria que o CPF/CNPJ pois é único, identifica o registro. Contudo nesse caso temos de analisar outro aspecto, tamanho ocupado. Supondo que não guardamos os dígitos nem traços, teremos um campo com tamanho 14. Na tabela de clientes temos esse registro e em todas as tabelas que possuam chave estrangeira para ela. Se usássemos um inteiro longo, teríamos na tabela de clientes adicionado 8 bytes por linha, e em todas as tabelas que possuam chave estrangeira para com ela adicionaríamos 8 bytes e tiraríamos o tamanho da string (15 bytes). Ou seja, diminuiríamos em cada linha de cada tabela 7 bytes. Colocando valores para teste, imaginemos que tenhamos 10000 clientes cadastrados, 1200000 pedidos (incluindo cancelados), 22000 telefones cadastrados (a tabela telefone teria uma chave estrangeira para indicar qual o cliente dono do mesmo) e 12400 endereços cadastrados (a tabela de endereços teria uma chave estrangeira para indicar qual o cliente dono do mesmo). Nota: os valores são de um período de uma base na qual trabalhei (arredondados), somente não posso mencionar o nome da empresa. Voltando ao caso, temos adicionados 8*10000 bytes na tabela clientes com relação a não termos essa chave artificial, e ganhamos 7 * (1200000+22000+12400) bytes, ou seja, neste caso o ganho de espaço (sem nem considerar as chaves em si, que também ocupam espaço em disco) seria considerável. Vários casos assim podem ter vantagem de chaves artificiais, mas precisamos tomar cuidado, isso não é lei, há exceções. Ainda não há provas concretas e irrefutáveis de que usar chaves naturais ou artificiais seja a melhor alternativa, talvez por nem ser possível isso, mas muitas vezes chaves artificiais são uma ótima adição. Recomendo que verifiquem se vale a pena o uso de chaves artificiais.
Atenciosamente, André. PS: a teoria relacional não trata de chaves artificiais ou naturais, não especifica nenhuma delas, trata de normalizações e relações entre conjuntos. Aliás, nem trata de banco de dados, banco de dados apenas usam a mesma, mas não são as únicas coisas que usam essa teoria matemática. PS2: No exemplo apresentado, por quê não usas o código INEP? 2010/1/4 Alexsander Rosa <[email protected]> > Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave > natural, o que é impossível porque inúmeros órgãos públicos compartilham o > mesmo CNPJ. Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais > usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro. > Para o pagamento de empenhos os nomes das escolas precisam estar corretos > até a última vírgula, não dá pra emitir a NF em nome da Secretaria e depois > mandar entregar na escola. É muito mais simples usar um SERIAL para código > de cliente do que tentar achar uma chave natural viável. > > Sou totalmente a favor de chaves naturais, uso sempre que possível, mas há > casos em que simplesmente não dá. > > 2010/1/4 Leandro DUTRA <[email protected]> > >> >> Não. Nunca falei isso. Falei que geralmente chave artificial é >> desnecessária; não que é sempre desnecessária. E, aliás, que o que >> menos me importa é qual seja a chave primária, ou qual chave será >> ‘exportada’ (não nesta discussão, talvez). >> (...) >> O problema não é a existência do SERIAL, é seu uso — e abuso. >> >> Para bom entendedor… fica claro que o que exijo é chave natural, >> independente de ser primária ou alternativa, e que prefiro que não >> haja artificial a não ser que o desempenho exija. >> >> >> > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
