Pourquoi les clés primaires ont-elles leurs propres noms?

D'un point de vue mathématique, étant donné qu'une table possède au plus une clé primaire, il semble être une décision de conception à courte vue de faire référence aux clés primaires par un nom arbitraire au lieu d'une simple propriété de table.

Par conséquent, pour changer une clé primaire de non cluster en cluster ou vice versa, vous devez d'abord rechercher son nom, puis la supprimer et enfin la lire.

Y a-t-il un avantage à utiliser des noms arbitraires que je ne vois pas ou existe-t-il un SGBD n'utilisant pas de noms arbitraires pour les clés primaires?

Edit 2011-02-22 (02/22/2011 pour ceux qui ne veulent pas trier leur date):

Permettez-moi d'afficher la fonction, avec laquelle vous pouvez dériver les noms d'une clé primaire à partir du nom de ses tables (en utilisant les premières tables système 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

Comme gbn déclare qu'aucune personne n'aime vraiment le nom généré, lorsque vous ne fournissez pas de nom explicite:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

Je viens de recevoir

PK__example___3213E83F527E2E1D

Mais pourquoi les noms dans les sysobjects doivent-ils être uniques? Il serait parfaitement correct d'utiliser exactement le même nom pour la table et sa clé primaire.

En procédant de cette façon, nous n'avons pas eu besoin de mettre en place des conventions de dénomination, qui pourraient être accidentellement violées.

Répond maintenant à Marian:

1. J'ai seulement utilisé la tâche de changer un cluster en une clé primaire non cluster comme exemple où j'ai besoin de connaître le nom réel du paquet pour pouvoir le supprimer.
2. Les choses n'ont pas besoin d'avoir des noms propres, il suffit qu'elles puissent être facilement désignées de manière unique. C'est la base de l'abstraction. La programmation orientée objet va dans ce sens. Vous n'avez pas besoin d'utiliser des noms différents pour des propriétés similaires de différentes classes.
3. C'est arbitraire, car c'est une propriété d'une table. Le nom de la table est tout ce que vous devez savoir si vous souhaitez l'utiliser.

Les clés primaires (et d'autres contraintes uniques) sont implémentées en tant qu'index et sont traitées exactement de la même manière - il n'est pas logique du point de vue du programmeur d'avoir des chemins de code séparés pour les PK et les index (cela doublerait le potentiel de bugs).

En plus d'être référencé par des clés étrangères, un PK n'est qu'une contrainte unique qui est à son tour implémentée en tant qu'index, donc changer les propriétés d'un PK équivaut à changer les propriétés de tout autre index. Le fait d'avoir un nom explicite signifie également qu'ils peuvent être référencés dans des conseils de requête comme tout autre index.

Je ne suis pas sûr de bien comprendre la question.

Si vous aviez un index sur une table et que vous vouliez / deviez changer l'index, n'auriez-vous pas également besoin de le changer selon son nom? Je suppose que vous pouvez rechercher l'ID d'objet pour l'index et faire la mise à jour de cette façon, mais les noms ont tendance à aider les gens à comprendre logiquement avec quel objet ils travaillent.

Donc, peut-être que la réponse est que si vous avez une convention de dénomination forte en cours d'utilisation (c'est-à-dire, name_PK pour une clé primaire), vous pourrez facilement identifier que vous travailliez avec la clé primaire de la table.

Je suppose que la même chose pourrait également être dite pour définir les relations FK. Je pense que l'utilisation des noms est faite pour l'interprétation logique, car les objets eux-mêmes ont tous des ID d'objet distincts.

Je dirais que c'est un détail d'implémentation pour la lisibilité humaine.

Les noms de contrainte sont facultatifs (dans SQL Server au moins), mais j'aimerais avoir PK_MyTablepour MyTableplutôt quePK_MyTabl___16feb6d8a

Historiquement, les clés primaires et les clés uniques sont toutes appelées clés candidates comme enseigné par Christopher J. Date.

Une clé candidate est un index unique qui peut jouer le rôle d'une clé primaire. Ainsi, toutes les clés candidates sont des clés uniques. Une clé primaire est simplement la désignation de l'une des clés candidates comme moyen préféré d'accéder aux données de la table.

À la lumière de cela, le nom PRIMARY KEY est le nom arbitraire de la clé candidate préférée attachée en tant que propriété de table. Il ne peut y avoir qu'une seule clé primaire.

En réalité, la création de clés candidates nommées devrait suffire.

Changer un index de cluster à non cluster et inversement serait juste un exercice de recherche de la CLÉ PRIMAIRE, qui est au plus 1 par définition. Je suppose que vous pouvez dire qu'avoir une définition de PRIMARY KEY est essentiellement un sentiment de nostalgie pour les puristes des bases de données. Ce sens de la pureté de la base de données aurait dû appeler des clés uniques par les mots-clés CANDIDATE KEY au lieu des mots UNIQUE KEY.

Cliquez ici pour voir la définition d'une clé candidate et les commentaires de CJDate à ce sujet

Il n'y a rien à dire que la clé primaire représentera l'objet table. L'objet table est l'index cluster, pas la clé primaire. Rien ne dit que la clé primaire doit être la même que l'index clusterisé. C'est souvent le cas, mais ce n'est pas obligatoire. La clé primaire peut facilement être appliquée par un index non clusterisé.