No meu artículo, http://www.utmag.com/May2002/Page14.asp, falo das vantagems de as duas alternativas. Veja também os comentários insertos embaixo.

>Alow! Alow! Alow!
>
>Estou com uma dúvida cruel... Tenho um sistema que a chave primária da tabela é o próprio código do produto. Exemplo da estrutura:
>

>PRODUTOS.DBF
>   CÓDIGO C (15) -> Primary Key
>   DESCRIÇÃO C (50)
>

>
>Tenho 2 alternativas para melhorar a estrutura acima...
>

>Alternativa 1
>   CHAVE I -> Primary Key
>   CÓDIGO C (15) -> Candidate
>   DESCRICAO C (50)
>
>Alternativa 2
>   CÓDIGO I -> Primary Key
>   DESCRICAO C (50)
>

>
>Meus comentários - Alternativa 1 x Alternativa 2:
>
>Usando a alternativa 1, a chave primária ficaria oculta ao usuário, que estaria visualizando apenas o campo código. O usuário poderia alterar livremente o campo código (desde que não fosse um valor repetido) sem perder a integridade dos dados (que seria feita através do campo chave) ... O usuário também poderia definir um formato para o código, algo do tipo: A-01, A-02, B-01, ... ou qualquer outra combinação lógica de letras / sequenciais. Até aqui, só vantagens para essa alternativa. Agora vem o abacaxi... Imagine no formulário de vendas, tenho uma grid listando os produtos, o usuário digitaria o valor referente ao campo código nesta grid, e eu encontraria a descrição. Até aqui tudo normal, a não ser pelo fato de eu ter que gravar o campo CHAVE do produto na tabela dos pedidos_itens. Toda vez eu teria que converter o valor CODIGO em um valor CHAVE, tanto na hora de gravar, quanto na hora de ler... Alguém tem alguma dica para resolver isso?

Isto pode precissar classes especiáis, que façem a conversão a os dois lados (de código interno para código visível, para ver os dados; e de código visível para o código interno, para guardar). Eu trabalho assim, e acho que o trabalho adicional é justificado, pelas vantagems que tem o uso de códigos internos (não visíveis para o ussuario).

>Usando a alternativa 2 o usuário não poderia nem definir o formato do seu código (A-01, etc...) nem alterar o campo código se necessário, já que o campo código e a chave primária seria uma só coisa... A grande vantagem está no desenvolvimento do sistema: eu não precisaria ficar convertendo código em chave primária e vice-versa... o usuário digitou o código (que seria um sequencial numérico) e se esse produto existir, era só jogar esse valor para a tabela, sem ter que procurar código e gravar chave primária...

Sim, algumas coisas são mais simples.

O usuario sím pode alterar a chave primaria, se vocé definir update triggers que atualizam em cascada. Vocé não precissa programar nada! Só fazer a definiçao. Porem, isto pode ser muito devagar, se a chave primaria é ussada em muitos registros, nas outras tabelas. (VFP tem que cambiar não só a chave primária, mas também a chave foránea, em centos ou miles de registros relacionados.)

Eu prefiro os códigos internos (a sua alternativa 1). Muitos programadores, aquí no UT, compartem a minha opiniao. E muitos outros, não.