¿Por qué las claves primarias tienen nombres propios?

Desde una vista matemática, dado que una tabla tiene como máximo una clave primaria, parece ser una decisión de diseño miope referirse a las claves primarias por algún nombre arbitrario en lugar de una simple propiedad de tabla.

Como consecuencia, para cambiar una clave primaria de no agrupada a agrupada o viceversa, primero debe buscar su nombre, luego soltarla y finalmente leerla.

¿Hay alguna ventaja en usar nombres arbitrarios que no veo o hay DBMS que no usa nombres arbitrarios para las claves primarias?

Editar 2011-02-22 (22/02/2011 para aquellos que no quieren ordenar la fecha):

Permítame mostrar la función, con la que puede derivar los nombres de una clave primaria del nombre de sus tablas (usando las primeras tablas del 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 dice gbn, a ninguna persona le gusta realmente el nombre generado, cuando no proporciona un nombre explícito:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

Acabo de tener

PK__example___3213E83F527E2E1D

Pero, ¿por qué los nombres en sysobjects deben ser únicos? Sería perfectamente correcto usar exactamente el mismo nombre para la tabla y su clave principal.

Al hacerlo de esa manera, no necesitábamos establecer convenciones de nomenclatura, que podrían violarse accidentalmente.

Ahora responde a Marian:

1. Solo utilicé la tarea de cambiar un clúster en una clave primaria no agrupada como un ejemplo en el que necesito saber el nombre real del paquete para poder soltarlo.
2. Las cosas no necesitan tener nombres propios, es suficiente si pueden denotarse fácilmente de manera única. Esa es la base de la abstracción. La programación orientada a objetos va de esta manera. No necesita usar nombres diferentes para propiedades similares de diferentes clases.
3. Es arbitrario, porque es una propiedad de una tabla. El nombre de la tabla es todo lo que necesita saber si desea usarlo.

Las claves primarias (y otras restricciones únicas) se implementan como índices, y se tratan exactamente de la misma manera: desde el punto de vista del programador no tiene sentido tener rutas de código separadas para PK e índices (duplicaría el potencial de errores).

Además de las referencias externas, una PK es solo una restricción única que a su vez se implementa como un índice, por lo que cambiar las propiedades de una PK es lo mismo que cambiar las propiedades de cualquier otro índice. También tener un nombre explícito significa que se puede hacer referencia a ellos en sugerencias de consulta como cualquier otro índice.

No estoy seguro de entender completamente la pregunta.

Si tuviera un índice en una tabla y quisiera / necesitara cambiar el índice, ¿no necesitaría también cambiarlo de acuerdo con su nombre? Supongo que podría buscar el ID de objeto para el índice y realizar la actualización de esa manera, pero los nombres tienden a ayudar a las personas a comprender lógicamente con qué objeto están trabajando.

Entonces, tal vez la respuesta es que si tiene una convención de nomenclatura fuerte en uso (es decir, name_PK para una clave primaria), entonces podrá identificar fácilmente que estaba trabajando con la clave principal de la tabla.

Supongo que lo mismo podría decirse también para definir las relaciones FK. Creo que el uso de nombres se realiza para la interpretación lógica, ya que todos los objetos tienen ID de objeto distintos.

Diría que es un detalle de implementación para la legibilidad humana.

Los nombres de restricción son opcionales (en SQL Server por lo menos), pero me gustaría tener PK_MyTablepara el MyTablelugar dePK_MyTabl___16feb6d8a

Históricamente, las claves primarias y las claves únicas se llaman claves candidatas según lo enseñado por Christopher J. Date.

Una clave candidata es un índice que es único y puede jugar el rol de una clave primaria. Por lo tanto, todas las claves candidatas son claves únicas. Una clave primaria es simplemente la designación de una de las claves candidatas como la forma preferida de acceder a los datos de la tabla.

A la luz de esto, el nombre PRIMARY KEY es el nombre arbitrario de la clave candidata preferida adjunta como una propiedad de tabla. Solo puede haber una Clave primaria.

En realidad, la creación de claves de candidatos con nombre solo debería ser suficiente.

Cambiar un índice de agrupado a no agrupado y viceversa sería solo un ejercicio para encontrar la CLAVE PRIMARIA, que es como máximo 1 por definición. Supongo que se puede decir que tener una definición de PRIMARY KEY es esencialmente una sensación de nostalgia para los puristas de bases de datos. Ese sentido de pureza de la base de datos debería haber llamado claves únicas por las palabras clave CANDIDATE KEY en lugar de las palabras reales UNIQUE KEY.

Haga clic aquí para ver la definición de una clave de candidato y los comentarios de CJDate sobre ella

No hay nada que decir que la clave primaria representará el objeto de la tabla. El objeto de la tabla es el índice agrupado, no la clave primaria. No hay nada que diga que la clave primaria tiene que ser la misma que el índice agrupado. A menudo lo es, pero no tiene que ser así. La clave primaria puede ser forzada fácilmente por un índice no agrupado.