Por que as chaves primárias têm nomes próprios?

Do ponto de vista matemático, desde que uma tabela tenha no máximo uma chave primária, parece ser uma decisão de projeto míope se referir às chaves primárias por algum nome arbitrário em vez de uma propriedade simples da tabela.

Como conseqüência, para alterar uma chave primária de não clusterizada para clusterizada ou vice-versa, primeiro você deve procurar pelo nome, depois soltá-lo e finalmente lê-lo.

Existe alguma vantagem no uso de nomes arbitrários que eu não vejo ou o DBMS não está usando nomes arbitrários para chaves primárias?

Edite 22-02-2011 (22/02/2011 para quem não quiser classificar a data):

Deixe meu show a função, com a qual você pode derivar os nomes de uma chave primária do nome de suas tabelas (usando as primeiras tabelas de sistema sql-sever aka sybase):

create function dbo.get_pk (@tablename sysname)
returns sysname
as
begin
    return (select k.name
    from sysobjects o 
        join sysobjects k   on k.parent_obj = o.id 
    where o.name = @tablename
    and o.type = 'U'
    and k.type = 'k')
end
go

Como afirma o gbn, ninguém gosta realmente do nome gerado, quando você não fornece um nome explícito:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

Eu acabei de receber

PK__example___3213E83F527E2E1D

Mas por que os nomes nos sysobjects devem ser exclusivos. Seria perfeitamente correto usar exatamente o mesmo nome para a tabela e sua chave primária.

Fazendo dessa maneira, não precisamos configurar convenções de nomenclatura, que podem ser violadas acidentalmente.

Agora as respostas para Marian:

1. Eu apenas usei a tarefa de alterar um cluster em uma chave primária não clusterizada como um exemplo em que preciso saber o nome real do pk para poder descartá-lo.
2. As coisas não precisam ter nomes próprios, é suficiente se puderem ser facilmente denotadas com exclusividade. Essa é a base da abstração. A programação orientada a objetos segue esse caminho. Você não precisa usar nomes diferentes para propriedades semelhantes de diferentes classes.
3. É arbitrário, porque é propriedade de uma tabela. O nome da tabela é tudo que você precisa saber se deseja usá-lo.

As chaves primárias (e outras restrições exclusivas) são implementadas como índices e são tratadas exatamente da mesma maneira - não faz sentido do ponto de vista do programador ter caminhos de código separados para PKs e índices (isso duplicaria o potencial para erros).

Além de ser referido por chaves estrangeiras, uma PK é apenas uma restrição exclusiva que, por sua vez, é implementada como um índice; portanto, alterar as propriedades de uma PK é o mesmo que alterar as propriedades de qualquer outro índice. Também ter um nome explícito significa que eles podem ser referidos em dicas de consulta como qualquer outro índice.

Não tenho certeza se entendi completamente a pergunta.

Se você tivesse um índice em uma tabela e desejasse / precisava alterar o índice, também não precisaria alterá-lo de acordo com o nome? Suponho que você possa procurar o objectID para o índice e fazer a atualização dessa maneira, mas os nomes tendem a ajudar as pessoas a entender logicamente com qual objeto elas estão trabalhando.

Portanto, talvez a resposta seja que, se você tiver uma forte convenção de nomenclatura em uso (ou seja, name_PK para uma Chave Primária), poderá identificar facilmente que estava trabalhando com a chave primária da tabela.

Suponho que a mesma coisa também possa ser dita para definir os relacionamentos FK. Eu acho que o uso de nomes é feito para interpretação lógica, pois todos os objetos têm IDs de objetos distintos.

Eu diria que é um detalhe de implementação para legibilidade humana.

Nomes de restrição são opcionais (em SQL Server, pelo menos), mas eu gostaria de ter PK_MyTablepara MyTable, em vez dePK_MyTabl___16feb6d8a

Historicamente, Chaves Primárias e Chaves Exclusivas são chamadas de Chaves Candidatas, conforme ensinado por Christopher J. Date.

Uma Chave Candidata é um índice que é Único e pode reproduzir o rolo de uma Chave Primária. Assim, todas as chaves candidatas são chaves exclusivas. Uma Chave Primária é simplesmente a designação de uma das Chaves Candidatas como a maneira preferida de acessar os dados da tabela.

À luz disso, o nome PRIMARY KEY é o nome arbitrário da chave candidata preferida anexada como uma propriedade da tabela. Só pode haver uma chave primária.

Na realidade, a criação de Chaves candidatas nomeadas apenas deve ser suficiente.

Alterar um índice de cluster para não clusterizado e voltar seria apenas um exercício de encontrar a PRIMARY KEY, que é no máximo 1 por definição. Eu acho que você pode dizer que ter uma definição de PRIMARY KEY é essencialmente uma sensação de nostalgia dos puristas de banco de dados. Esse senso de pureza do banco de dados deveria ter chamado chaves únicas pelas palavras-chave CANDIDATE KEY em vez das palavras reais UNIQUE KEY.

Clique aqui para ver a definição de uma chave de candidato e os comentários do CJDate sobre ela

Não há nada a dizer que a chave primária representará o objeto da tabela. O objeto de tabela é o índice em cluster, não a chave primária. Não há nada que diga que a chave primária deve ser a mesma que o índice em cluster. Muitas vezes é, mas não precisa ser. A chave primária pode facilmente ser aplicada por um índice não agrupado em cluster.