Warum haben Primärschlüssel eigene Namen?

Aus mathematischer Sicht scheint es eine kurzsichtige Entwurfsentscheidung zu sein, Primärschlüssel durch einen beliebigen Namen anstelle einer einfachen Tabelleneigenschaft zu referenzieren, vorausgesetzt, dass eine Tabelle höchstens einen Primärschlüssel hat.

Um einen Primärschlüssel von "nicht gruppiert" in "gruppiert" oder umgekehrt zu ändern, müssen Sie zuerst nach seinem Namen suchen, ihn dann löschen und schließlich erneut lesen.

Gibt es einen Vorteil bei der Verwendung von willkürlichen Namen, die ich nicht sehe, oder gibt es ein DBMS, das keine willkürlichen Namen für Primärschlüssel verwendet?

Edit 2011-02-22 (02/22/2011 für diejenigen, die das Datum nicht sortieren möchten):

Lassen Sie mich die Funktion zeigen, mit der Sie die Namen eines Primärschlüssels aus seinem Tabellennamen ableiten können (unter Verwendung früherer SQL-Server- oder Sybase-Systemtabellen):

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

Wie gbn sagt, mögen keine Leute den generierten Namen wirklich, wenn Sie keinen expliziten Namen angeben:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

Ich habe gerade bekommen

PK__example___3213E83F527E2E1D

Aber warum müssen Namen in sysobjects eindeutig sein? Es wäre vollkommen in Ordnung, für die Tabelle und ihren Primärschlüssel genau denselben Namen zu verwenden.

Auf diese Weise mussten wir keine Namenskonventionen einrichten, die versehentlich verletzt werden könnten.

Nun Antworten zu Marian:

1. Ich habe nur die Aufgabe verwendet, einen gruppierten in einen nicht gruppierten Primärschlüssel zu ändern, als Beispiel, bei dem ich den tatsächlichen Namen des Pakets kennen muss, um ihn löschen zu können.
2. Dinge müssen keine Eigennamen haben, es reicht aus, wenn sie leicht eindeutig bezeichnet werden können. Das ist die Basis der Abstraktion. Objektorientierte Programmierung geht so. Sie müssen keine unterschiedlichen Namen für ähnliche Eigenschaften verschiedener Klassen verwenden.
3. Es ist willkürlich, weil es eine Eigenschaft einer Tabelle ist. Der Name der Tabelle ist alles, was Sie wissen müssen, wenn Sie es verwenden möchten.

Primärschlüssel (und andere eindeutige Einschränkungen) werden als Indizes implementiert und genauso behandelt. Aus Sicht des Programmierers ist es nicht sinnvoll, getrennte Codepfade für PKs und Indizes zu haben (dies würde die Werte verdoppeln) Potenzial für Bugs).

Ein PK ist keine Fremdschlüssel-Referenz, sondern lediglich eine eindeutige Einschränkung, die wiederum als Index implementiert wird. Das Ändern der Eigenschaften eines PK ist also dasselbe wie das Ändern der Eigenschaften eines beliebigen anderen Index. Ein expliziter Name bedeutet auch, dass auf sie in Abfragetipps wie auf jeden anderen Index verwiesen werden kann.

Ich bin nicht sicher, ob ich die Frage vollständig verstehe.

Wenn Sie einen Index für eine Tabelle hätten und den Index ändern wollten / mussten, müssten Sie ihn dann nicht auch entsprechend seinem Namen ändern? Ich nehme an, Sie könnten die objectID für den Index nachschlagen und das Update auf diese Weise durchführen, aber die Namen helfen den Leuten, logisch zu verstehen, mit welchem ​​Objekt sie arbeiten.

Vielleicht lautet die Antwort: Wenn Sie eine starke Namenskonvention verwenden (dh name_PK für einen Primärschlüssel), können Sie leicht erkennen, dass Sie mit dem Primärschlüssel der Tabelle gearbeitet haben.

Ich nehme an, dasselbe gilt auch für die Definition von FK-Beziehungen. Ich denke, die Verwendung von Namen erfolgt zur logischen Interpretation, da die Objekte selbst alle unterschiedliche objectIDs haben.

Ich würde sagen, es ist ein Implementierungsdetail für die menschliche Lesbarkeit.

Einschränkungsnamen sind optional (zumindest in SQL Server), aber ich hätte lieber PK_MyTablefür MyTablealsPK_MyTabl___16feb6d8a

In der Vergangenheit werden Primärschlüssel und eindeutige Schlüssel von Christopher J. Date als Kandidatenschlüssel bezeichnet.

Ein Kandidatenschlüssel ist ein eindeutiger Index, der die Rolle eines Primärschlüssels spielen kann. Somit sind alle Kandidatenschlüssel eindeutige Schlüssel. Ein Primärschlüssel ist einfach die Bezeichnung eines der Kandidatenschlüssel als bevorzugte Methode für den Zugriff auf Tabellendaten.

Vor diesem Hintergrund ist der Name PRIMARY KEY der beliebige Name des bevorzugten Kandidatenschlüssels, der als Tabelleneigenschaft angehängt ist. Es kann nur einen Primärschlüssel geben.

In Wirklichkeit sollte es ausreichen, nur benannte Kandidatenschlüssel zu erstellen.

Das Ändern eines Index von Clustered zu Nonclustered und zurück wäre nur eine Übung des Findens des PRIMARY KEY, der per Definition höchstens 1 ist. Man kann wohl sagen, dass eine PRIMARY KEY-Definition im Grunde genommen ein Gefühl der Nostalgie für Datenbank-Puristen ist. Dieses Gefühl der Datenbankreinheit sollte eindeutige Schlüssel mit den Schlüsselwörtern CANDIDATE KEY anstelle der tatsächlichen Wörter UNIQUE KEY genannt haben.

Klicken Sie hier, um die Definition eines Kandidatenschlüssels und die Kommentare von CJDate dazu anzuzeigen

Es gibt nichts zu sagen, dass der Primärschlüssel das Tabellenobjekt darstellt. Das Tabellenobjekt ist der Clustered-Index und nicht der Primärschlüssel. Nichts besagt, dass der Primärschlüssel mit dem Clustered-Index identisch sein muss. Oft ist es das, aber es muss nicht so sein. Der Primärschlüssel kann problemlos von einem nicht gruppierten Index erzwungen werden.