Perché le chiavi primarie hanno nomi propri?

Da un punto di vista matematico, dato che una tabella ha al massimo una chiave primaria, sembra essere una decisione progettuale miope fare riferimento alle chiavi primarie con un nome arbitrario anziché una semplice proprietà della tabella.

Di conseguenza, per cambiare una chiave primaria da non cluster a cluster o viceversa, devi prima cercare il suo nome, quindi rilasciarlo e infine leggerlo.

C'è qualche vantaggio nell'uso di nomi arbitrari che non vedo o ci sono DBMS che non usano nomi arbitrari per le chiavi primarie?

Modifica 22/02/2011 (22/02/2011 per coloro che non vogliono ordinare lì la data):

Lascia che mostri la funzione, con la quale puoi derivare i nomi di una chiave primaria dal nome della sua tabella (usando le prime tabelle di 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

Come afferma gbn, a nessuno piace molto il nome generato, quando non si fornisce un nome esplicito:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

ho appena ottenuto

PK__example___3213E83F527E2E1D

Ma perché i nomi negli oggetti di sistema devono essere univoci. Sarebbe perfettamente OK utilizzare esattamente lo stesso nome per la tabella e la sua chiave primaria.

In questo modo, non è stato necessario stabilire convenzioni di denominazione, che potrebbero essere violate accidentalmente.

Ora risponde a Marian:

1. Ho usato solo il compito di cambiare un cluster in una chiave primaria non cluster come esempio in cui ho bisogno di conoscere il nome effettivo del pk per poterlo rilasciare.
2. Le cose non hanno bisogno di avere nomi propri, è sufficiente che possano essere facilmente indicate in modo univoco. Questa è la base dell'astrazione. La programmazione orientata agli oggetti va in questo modo. Non è necessario utilizzare nomi diversi per proprietà simili di classi diverse.
3. È arbitrario, perché è una proprietà di una tabella. Il nome della tabella è tutto ciò che devi sapere se vuoi usarlo.

Le chiavi primarie (e altri vincoli univoci) sono implementate come indici e trattate esattamente allo stesso modo: non ha senso dal punto di vista del programmatore avere percorsi di codice separati per PK e indici (raddoppierebbe il potenziale di bug).

Oltre a essere indicato da chiavi esterne, un PK è solo un vincolo unico che viene a sua volta implementato come un indice, quindi cambiare le proprietà di un PK equivale a cambiare le proprietà di qualsiasi altro indice. Avere anche un nome esplicito significa che possono essere citati nei suggerimenti di query come qualsiasi altro indice.

Non sono sicuro di aver compreso appieno la domanda.

Se avessi un indice su una tabella e volessi / avessi bisogno di cambiare l'indice, non avresti bisogno di cambiarlo in base al suo nome? Suppongo che potresti cercare objectID per l'indice e fare l'aggiornamento in quel modo, ma i nomi tendono ad aiutare le persone a comprendere logicamente con quale oggetto stanno lavorando.

Quindi, forse la risposta è che se si utilizza una convenzione di denominazione forte (ad esempio, name_PK per una chiave primaria), si sarebbe in grado di identificare facilmente che si stava lavorando con la chiave primaria della tabella.

Suppongo che si possa dire la stessa cosa anche per definire le relazioni FK. Penso che l'uso dei nomi sia fatto per l'interpretazione logica, poiché gli oggetti stessi hanno tutti ID oggetto distinti.

Direi che è un dettaglio di implementazione per la leggibilità umana.

Nomi di vincolo sono opzionali (in SQL Server almeno), ma mi piacerebbe avere PK_MyTableper MyTablepiuttosto chePK_MyTabl___16feb6d8a

Storicamente, le chiavi primarie e le chiavi uniche sono tutte chiamate chiavi candidate come insegnato da Christopher J. Date.

Una chiave candidata è un indice che è unico e può svolgere il ruolo di chiave primaria. Pertanto, tutte le chiavi candidate sono chiavi uniche. Una chiave primaria è semplicemente la designazione di una delle chiavi candidate come modo preferito per accedere ai dati della tabella.

Alla luce di ciò, il nome PRIMARY KEY è il nome arbitrario della chiave candidata preferita allegata come proprietà della tabella. Può esserci solo una chiave primaria.

In realtà, è sufficiente creare solo chiavi nominate.

Cambiare un indice da cluster a non cluster e viceversa sarebbe solo un esercizio per trovare il PRIMARY KEY, che è al massimo 1 per definizione. Immagino che si possa dire che avere una definizione PRIMARY KEY è essenzialmente un senso di nostalgia per i puristi del database. Quel senso di purezza del database avrebbe dovuto chiamare chiavi uniche con le parole chiave CANDIDATE KEY anziché le parole reali UNIQUE KEY.

Fai clic qui per vedere la definizione di una chiave candidata e i commenti di CJDate su di essa

Non c'è nulla da dire che la chiave primaria rappresenterà l'oggetto tabella. L'oggetto tabella è l'indice cluster, non la chiave primaria. Non c'è nulla che dica che la chiave primaria deve essere la stessa dell'indice cluster. Spesso lo è, ma non deve esserlo. La chiave primaria può essere facilmente applicata da un indice non cluster.